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Appellants submit this brief in accordance with the provisions of 37 C.F.R. § 41.37 in 
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I. REAL PARTY IN INTEREST (37 C.F.R. §41.37 (c^lKD) 

The real party in interest is the assignee MyEtribute, Inc. by virtue of an assignment 
executed by the inventors. The assignment was recorded in the U.S. Patent and Trademark 
Office on May 7, 2002 at Reel/Frame 012880/0753. 
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II. RELATED APPEALS AND INTERFERENCES (37 C.F.R. §41.37 (c)(l)(im 

There are no related appeals or interferences. 

III. STATUS OF CLAIMS (37 C.F.R. $41.37 (cMlMiiffl 

Claims 1, 4, 6-1 1 and 19-24 are pending. Claims 2, 3, and 5 are canceled and claims 12- 
1 8 are withdrawn. 

Claims 1, 4, 6-1 1 and 19-24 are rejected under 35 U.S.C. § 1 12, first paragraph. Claims 
1, 4, 6-1 1 and 19-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over Davis et al. 
(US 6,105,008) in view of Johansen Jr., (US 6,785,938). Appellant appeals the rejections of 
claims 1, 4, 6-1 1 and 19-24. 

IV. STATUS OF AMENDMENTS (37 C.F.R. S41.37 (c)(l)(iv» 

Appellants submitted an amendment to claim 10 subsequent to the final rejection mailed 
12/29/05. The proposed amendment would make claim 10 depend from dependent claim 6 
instead of cancelled claim 5. Both claims 6 and 5 depend from independent claim 1 . The 
Examiner did not enter the amendment stating that the amendment to claim 1 0 required "further 
search consideration." It is questioned how such an amendment could possibly involve a 
"further search consideration," assuming a complete search had been done on the first Office 
Action. 

V. SUMMARY OF CLAIMED SUBJECT MATTER (37 C.F.R. §41.37 (c)(l)(v» 

The published version of the application serial number 10/001,420 (US Patent 
Application Publication US 2002/0178079) is used for all references herein. 

Independent claim 1 relates to a method of conducting pet death, or pet related 
transactions over the Internet by providing at least one computer server for starting a client 
session, sending a command to start a client program, receiving commands from a remote 
computer, passing commands to a software session, and transmitting data to a remote computer. 
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In addition, the computer server hosts one or more Internet web sites containing information and 
services related to the death of a pet and pet related information and services (paragraph [0036] 
and FIG. 1). Remote users are permitted to establish accounts and obtain information regarding 
or order pet death or pet related services from a plurality of associated sources and vendors 
(paragraphs [0016], [0036-0037] and [0043] and FIGs. 1, 1A and 1 1). Remote users are charged 
for obtaining information regarding or order pet death or pet related services from a plurality of 
associated sources and vendors via established accounts (paragraph [0039], and FIGs. 3, 5). 

Independent claim 19 relates to a method of conducting pet-related transactions over the 
Internet by providing at least one computer server for starting a client session, sending a 
command to start a client program, receiving commands from a remote computer, passing 
commands to a software session, and transmitting data to a remote computer (paragraph [0036] 
and FIG. 1). A pet calculator is provided that prompts specific input from a remote user, 
analyzes the input, and provides results and feedback to the remote user based on the input 
(paragraphs [0040-0044]). There is also provided a pet selector that prompts specific input from 
a remote user, analyzes at least a portion of the input, and provides customized recommendations 
to the remote user (paragraphs 0046-0047). Remote users are permitted to establish accounts 
and obtain information regarding or order pet death or pet related services from a plurality of 
associated sources and vendors (paragraphs [0016], [0036-0037] and [0043] and FIGs. 1, 1 A and 
11). Remote users are charged for obtaining information regarding or order pet death or pet 
related services from a plurality of associated sources and vendors via established accounts 
(paragraph [0039], and FIGs. 3, 5). 

Independent claim 21 provides a method of conducting transactions over the Internet 
related to commemorate the passing of a pet by providing at least one computer server for 
starting a client session, sending a command to start a client program, receiving commands from 
a remote computer, passing commands to a software session, and transmitting data to a remote 
computer (paragraph [0036] and FIG. 1). Remote users are permitted to establish accounts and 
obtain information or conduct transactions over the Internet related to commemorate the passing 
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of a pet from a plurality of associated sources and vendors (paragraphs [0016], [0036-0037] and 
[0043], FIGs. 1, 1 A and 11 and Situational Examples 1 and 2 in paragraphs [0048 -0106]). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL (37 C.F.R. §41.37 

1. Whether claims 1, 4, 6-1 1 and 19-24 are properly rejected under 35 U.S.C. § 1 12, first 
paragraph. 

2. Whether claims 1, 4, 6-1 1 and 19-24 are properly rejected under 35 U.S.C. 103(a) as 
being unpatentable over Davis et al., US 6,105,008 ("Davis") in view of Johansen Jr., US 
6,785,938 ("Johansen"). 

VII. ARGUMENTS (37 C.F.R. S41.37 (c)(l)(vim 

For the reasons set forth below, Appellant believes that claims 1, 4, 6-1 1 and 19-24 are 
improperly rejected under 35 U.S.C. § 1 12, first paragraph and 35 U.S.C. 103(a). 

A. Claim Rejections Under 35 U.S.C. 112, Second Paragraph ; 

The Examiner rejected claims 1, 4, 6-1 1 and 19-24 under 35 U.S.C. 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which Applicant regards as the invention. In particular, the Examiner states that: 

Claim 1, lines 1, 4, 9 "pet death" is not clear as to its meaning. 

Claims 1, line 12 "regarding or order pet death" is not clear as to its meaning. 

Claim 19, line 17 "regarding or ordering pet-related services" is not clear to its meaning. 

Claim 21, line 2 "the passing" lacks antecedent basis and is not clear as to its meaning. 

The Examiner bears the burden to present a prima facie case of indefiniteness for a 
rejection under 35 U.S.C. 1 12, second paragraph (see MPEP, 2173). The Examiner's focus 
during the examination of claims is whether the claim meets the threshold requirements of clarity 
and precision. (MPEP 2173.02). The Examiner has not presented a prima facie case for 
indefiniteness for each of the rejections under 35 U.S.C. 112, second paragraph. The Examiner 
provides no basis for the Appellant to know whether any analysis was done or the results of any 
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analysis of the allegedly indefinite claim language in view of (A) the content of the patent 
application disclosure; (B) the teachings of the prior art; and (C) the claim interpretation that 
would be given by one possessing the ordinary level of skill in the pertinent art at the time the 
invention was made (MPEP 2173.02). 

Appellant suggests that the Examiner is reading incorrectly parsing portions of the claims 
and leading to confusion. 

The allegedly indefinite term "pet death" in claim 1 line 1 is considered as modifying 
"transactions" and is set off in the alternative with "pet related" which also modifies transactions. 
The specification is replete with examples of at least the passing of pets, death of pets, mourning 
the death of a pet and mourning the death of VIP pets, and the descriptions in paragraphs [0016- 
0017], [0019], [0040-0106]. (All cites are to the published version of the application US Patent 
Application Publication US 2002/0178079). For at least these reasons, the term "pet death" has 
definite meaning in the context of the patent application disclosure. 

The allegedly indefinite phrase "regarding or order pet death" in claim 1, at line 12 is not 
being considered in the full context of the claim. In context, it is clear that the claimed remote 
users may do two things, namely, first, obtain information regarding or, second, order. What is 
the information regarding or what is ordered is provided in the next portion of the claim. Again, 
set out in the alternative, the remote users may obtain information regarding or order two things. 
The two things available to the remote users are both services - pet death services or pet related 
services. For the reasons stated in the paragraph above, the specification provides numerous 
examples of pet death and pet related services thereby making clear the meaning of these terms 
in the context of the specification. The same reasoning applies to the allegedly indefinite phrase 
"regarding or ordering pet-related services" in claim 19, line 17. 

The allegedly indefinite phrase "the passing" in claim 21, line 2 is only so by incorrect 
parsing of the claim element by the Examiner. Viewing the term in context reveals that the 
complete phrase is "to commemorate the passing of a pet." As set forth above, the various 
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aspects of mourning and commemorating the death or passing of a pet are described at length in 
the specification. 

For at least the reasons set forth above, the Examiner has not made out a prima facie case 
of indefiniteness. Even if such a case had been presented, the allegedly indefinite terms are in 
fact definite for at least the reasons set forth above. In view of the forgoing, it is requested that 
the rejections under 35 USC §112, first paragraph be withdrawn. 

B. Claim Rejections Under 35 U.S.C. 103 : 

The Examiner rejected claims 1, 4, 6-1 1 and 19-24 are rejected under 35 U.S.C. §103(a) 
as being unpatentable over Davis et al., US 6,105,008 ("Davis") in view of Johansen Jr., US 
6,785,938 ("Johansen"). 

Davis relates to an online electronic bill paying architecture and system. Johansen 
describes a customizable pet urn manufacturing process. 

The Examiner bears the burden of providing a prima facie case of obviousness of a claim 
in view of the cited references. Included within the prima facie case is the identification of some 
reason, suggestion or motivation from the prior art as a whole for a person of ordinary skill in the 
art to have modified or combined the references. When the incentive to combine the teachings 
of the references is not readily apparent as is here, it is the duty of the Examiner to explain why 
the combination is proper. This has not been done. 

The motivation to combine references in an obviousness rejection must come from the 
references themselves. No such motivation exists here. Instead, the Examiner is using the 
pending claims to identify some reason to combine. It is plainly evident that Davis's online bill 
payment system has no relation to an automated urn design and manufacturing process. 
Similarly, Johansen's description an automated urn design and manufacturing process is not 
furthered or advantaged by Davis's online bill payment system. 

Because the Examiner has not provided a prima facie showing of how independent 
claims 1,19 and 21 are obvious in view Davis and Johansen, Appellant requests that the 
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rejection be withdrawn. Because independent claims 1, 19 and 21 are not rendered obvious and 
are allowable, the dependent claims 4, 6, 7, 8, 9 10, 1 1, 20, 22, 23, and 24 are also allowable. 

For the reasons stated above, claims 1, 4, 6-1 1 and 19-24 are patentable over the prior art 
of record, and the rejections those claims under 35 U.S.C. §1 12, second paragraph and 35 U.S.C. 
§103 (a) are improper and should be withdrawn. Appellants respectfully ask the Board to 
overturn the Examiner's rejection with instructions to allow the claims. 

The Commissioner is authorized to charge any fees that may be required in connection 
with this submission, including petition fees and extension of time fees, and to credit any 
overpayments to Deposit Account No. 23-2415 (Attorney Docket No. 30841-703.201). 

Respectfully submitted, 

DM.: /Hr^lO. 2QO L By: Q k»J I/A *-. 

Albert P. Halluin, Reg. No. 25,227 

WILSON SONSINI GOODRICH & ROSATI 

650 Page Mill Road 

Palo Alto, CA 94304-1050 

(650) 493-9300 

Customer No. 021971 
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APPENDIX 1 CLAIMS APPENDIX (37 C.F.R. §41.37 (cMlVviiffl 



1 . (Previously Presented) A method of conducting pet death, or pet related transactions 
over the Internet, comprising: 

(a) providing at least one computer server for hosting one or more Internet web sites 
containing information and services from the group consisting of pet death, and pet related 
information and services, said at least one computer server capable of starting a client session, 
sending a command to start a client program, receiving commands from a remote computer, 
passing commands to a software session, and transmitting data to a remote computer; 

(b) permitting remote users to establish accounts, whereby said remote users may obtain 
information regarding or order pet death or pet related services from a plurality of associated 
sources and vendors; and 

(c) charging said remote users via their established accounts for obtaining information 
regarding or order pet death or pet related services from a plurality of associated sources and 
vendors. 

4. (Previously Presented) The method of claim 1, wherein said pet death related 
transaction, information, and services pertain to the death of a famous or an important 
individuals pet. 

6. (Previously Presented) The method of claim 1, wherein said services include 
comprises a pet calculator, whereby said pet calculator prompts specific input from a remote 
user, analyzes at least a portion of said input, and provides results and feedback to the remote 
user based on at least a portion of said input. 

7. (Original) The method of claim 6, wherein said pet calculator combines at least a 
portion of said input with set parameters for various species and breeds of pets before providing 
customized results and feedback to the remote user based on said input. 

8. (Original) The method of claim 6, wherein said pet calculator divides animals into a 
plurality of age classifications, assigns one or more specific age classifications to a particular pet 
based upon said specific input, and provides results and feedback to the remote user based upon 
said one or more assigned age classifications. 
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9. (Original) The method of claim 6, wherein at least one portion of said results and 
feedback contains at least a portion of said specific input while at least another portion of said 
results and feedback contains standardized generic passages that do not contain any of said 
specific input. 

10. (Previously Presented) The method of claim 6, wherein said pet related services 
include further comprising a pet selector, whereby said pet selector prompts specific input from a 
remote user, analyzes at least a portion of said input, and provides customized recommendations 
on pet selection to the remote user based on at least a portion of said input. 

1 1 . (Original) The method of claim 10, wherein said pet selector provides 
recommendations as to specific species and breeds of pets based upon one set of specific input. 

19. (Previously Presented) A method of conducting pet-related transactions over the 
Internet, comprising: 

(a) providing at least one computer server for hosting one or more Internet web sites 
containing pet-related information and services, said at least one computer server capable of 
starting a client session, sending a command to start a client program, receiving commands from 
a remote computer, passing commands to a software session, and transmitting data to a remote 
computer, wherein said pet related services include a pet calculator that prompts specific input 
from a remote user, analyzes at least a portion of said input, and provides results and feedback to 
the remote user based on at least a portion of said input, and wherein said pet related services 
also include a pet selector, whereby said pet selector prompts specific input from a remote user, 
analyzes at least a portion of said input, and provides customized recommendations on pet 
selection to the remote user based on at least a portion of said input; 

(b) permitting remote users to establish accounts, whereby said remote users may obtain 
information regarding or order pet-related services from a plurality of associated sources and 
vendors; and 

(c) charging said remote users via their established accounts for obtaining information 
regarding or ordering pet-related services from a plurality of associated sources and vendors. 
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20. (Original) The method of claim 19, wherein at least a portion of said pet related 
information or services are provided by outside vendors in business partnerships with the 
proprietor of said at least one computer server. 

21. (Previously Presented) A method of conducting transactions over the Internet related 
to commemorate the passing of a pet, comprising: 

(a) providing at least one computer server for hosting one or more Internet web sites 
containing information and services related to commemorate the passing of a pet, said at least 
one computer server capable of starting a client session, sending a command to start a client 
program, receiving commands from a remote computer, passing commands to a software 
session, and transmitting data to a remote computer; and 

(b) permitting remote users to establish accounts, whereby said remote users may obtain 
information or conduct transactions over the Internet related to commemorate the passing of a 
pet from a plurality of associated sources and vendors using the established accounts. 

22. (Previously Presented) A method of conducting transactions over the Internet related 
to commemorate the passing of a pet according to claim 21 further comprising arranging for 
payment from said remote users via their established accounts. 

23. (Previously Presented) A method of conducting transactions over the Internet related 
to commemorate the passing of a pet according to claim 21 wherein information and services 
related to commemorate the passing of a pet comprises an Internet site that enables a user to post 
or view death notices, obituaries, electronic announcements or tributes to a deceased pet. 

24. (Previously Presented) A method of conducting transactions over the Internet related 
to commemorate the passing of a pet according to claim 21 wherein at least one remote user is an 
owner of a deceased pet. 
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APPENDIX 2 EVIDENCE APPENDIX (37 C.F.R. S41.37 (cKlHix)) 

US 6,785,938 ("Johansen") is cited by Examiner in the final office action mailed on December 
29, 2005. 

US 6,105,008 ("Davis") is cited by Examiner in the final office action mailed on December 29, 
2005. 

Manual of Patent Examining Procedure ("MPEP") section 2173.02 cited by Appellant in 
response to final office action mailed 2/28/06. 
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(57) ABSTRACT 
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supporting base that is adapted to receive said cremated 
remains. 
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1 

PET CREMATORY URN 

TECHNICAL FIELD OF THE INVENTION 

This invention relates generally to crematory urns for pets 
and particularly to customized crematory ums for pets. 

BACKGROUND OF THE INVENTION 
Cremation is a means of disposing of the remains of the 
deceased. From time immemorial, various vessels such as 
vases, jars and urns have been used as a repository for the 
cremated remains of humans. Many of these retainers pay 
tribute to a deceased individual through various means. 
Some urns are made with ornate decorations and fitted with 
jewelry, while others are formed in the likeness of cherished 
objects. 

Although the prior art teaches many improvements to 
cremation urns for human remains, there are scant few 
disclosures of cremation urns for pets. For example, the art 
of human cremation urns, as previously disclosed, includes, 
U.S. Pat. No. 2,562,726, teaching an urn for ashes with a 
screw in stopper; U.S. Pat. Nos. 2,385,520, 2,235,617, and 
2,075,859 teaching cremation ums with a screw-in stoppers; 
U.S. Pat. No. 4,324,026 teaching an urn with compartment 
for memorabilia of the deceased; and U.S. Pat. Des. No. 
232,782 teaching an urn formed as a statue or bust. All of the 
above referenced art is with respect to vessels for human 
remains and not animals and specifically pets. 

As this indicates, pet owners have had very few choices 
in electing to preserve the ashes of a beloved pet. Given the 
means, however, pet owners would choose to preserve their 
pet's cremated remains in an urn that evokes the likeness and 
the particular physical attributes and memories of a cher- 
ished pet. An urn bearing a close or nearly exact likeness of 
a family or personal pet would be a preferred means to keep 
alive the memories of one's pet. Presently, there are very few 
devices designed for storing and preserving the ashes of a 
beloved pet. In this regard, there are even fewer choices for 
pet urns that also memorialize the pet in a three-dimensional 
representation of the pet's likeness. The present invention 
provides a final resting place for the remains of a cherished 
pet in an urn customized in the form of the pet's likeness and 
that provides an improved means for accessing the reposi- 
tory chamber in which the ashes are stored. 

History teaches that human beings have a tendency to 
form strong emotional attachments to specially chosen pets. 
Only recently, however, have pet owners had the freedom of 
resources to treat their pets to many of perquisites usually 
reserved for humans. Pet owners now provide for their pets 
in lavish and sometimes exorbitant ways, including custom- 
built air-conditioned doghouses, treatments by animal 
psychologists, luxurious grooming, hairstyling and polish- 
ing of nails, etc. Accordingly, the industry catering to 
specialty pet products and services has seen tremendous 
growth in recent years. 

This trend of treating one's pet in every respect as family 
member has produced a need for providing pet owners with 
a means for memorializing the life of a cherished pet after 
its death. The emotional bond between owner and pet creates 
the need for bereavement services and funerary products for 
pets. This is evidenced by the increasingly popular practice 
of selling burial plots for pets and conducting formal intern- 
ment ceremonies for the pets. The sale of pet burial plots in 
pet cemeteries has become a formidable business enterprise, 
catering to all the needs of bereaved pet owners. These 
practices may involve, for example, memorial services, 
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caskets and the like in an attempt to replicate human burial 
ceremonies. Crematoriums have also started to cater spe- 
cifically to bereaved pet owners, sometimes arranging for a 
fitting ceremony during which a pet's ashes may be dis- 
5 persed. 

Sometimes the ashes are retained in a crematory urn, 
typically displayed in a special place in the home of the pet 
owner. However, many such urns are expensive and yet do 
not fittingly memorialize the life of the pet. Many pet owners 

10 would find it desirable, given the means, to keep their pet's 
ashes in an urn that allows them to evocatively reflect upon 
and recollect the life of their pet. Toward that goal, the 
present invention provides a final resting place for the 
cremated remains of the pet formed in a replica of the animal 

15 whose remains are contained therein. 

Among the prior art, one pet urn comprises a cremation 
receptacle with a decorative housing bearing a stylized 
likeness of a pet such as a dog or cat as disclosed in U.S. Pat. 
No. 6,023,822. Although this urn generally discloses a 

20 storage receptacle in the stylized likeness of the deceased 
pet, many of its features as a storage receptacle warrant 
improvement. For instance, the prior art shows a chamber 
for holding the ashes with an opening located, preferably on 
the bottom of the urn where it is difficult to access, particu- 

25 larly where the urn is made of a heavy material. In this case, 
it is necessary to turn the um over on its side or its head in 
order to access the chamber opening, with the unfortunate 
consequence of increasing the risk of dropping and breaking 
the urn, particularly a heavy ceramic urn. Even more 

30 particularly, the prior art discloses a complicated threaded 
receptacle system wherein one chamber is threaded into a 
receptacle, which in turn, is then sealed by a threaded screw 
cap or screw plug. The above -described system, with its 
restricted access to the storage chamber and its difficult-to- 

3S operate sealing system provides an impediment to the use 
and enjoyment, as well as to the functionality of the pet urn. 
In so far as it is likely that many of the bereaved pet urn users 
are elderly and/or frail, the need for an easy to use pet urn 
becomes all the more important. 

Moreover, the pet urns of the prior art comprise molded, 
sculpted, cast, or extruded material forming the decorative 
shell of the urn. These stylized urns of the prior art bear only 
a distant resemblance to the deceased pels because they lack 

45 realistic general features such as fur, whiskers as well as the 
individual markings that characterize the true likeness of the 
deceased pet. The prior art decorative housings may perform 
a decorative function, but they fall well short of a true 
likeness of the deceased pet. 

50 It would be preferable to pet owners to have an urn that 
is a very close likeness of their deceased pet as opposed to 
a generic version of a pet breed. It would also be preferable 
to have a pet urn that provides ease of use and ease of access 
to the repository chamber. It is also preferable to develop a 

55 pet urn with the above characteristics that also has a sup- 
porting base for the urn, providing stability and an even 
more easily accessible chamber for the storage of ashes 
without the need for a separate sealable container. 

SUMMARY OF THE INVENTION 
This invention provides an improved devise comprising a 
decorative urn for the convenient reception and storage of 
ashes of deceased pets such that the ashes may be easily, 
securely and conveniently stored and displayed in the cus- 
65 tomized likeness of the deceased pet. The pet crematory urn 
of the present invention comprises a customized figurine or 
statue designed and crafted in the likeness of the deceased 
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pet and, further, provides easy access to a repository cham- depict features that the customer requests. Finally, the 
ber for the preservation and storage of the ashes of the pet. graphical representation is downloaded to the production 
The present invention also provides a figurine or statue facility that produces an individualized customized urn in 
customizable to substantially the exact likeness of the that exact likeness. This entire process may take place over 
deceased pet, including, at the customer's optional request, 5 the Internet; through email, phone calls and U.S. mail; or by 
fur, whiskers, and color markings that match those of the in-person consultation with the customer. Moreover, pre- 
deceased pet. Finally, the present invention also provides a need urns may be produced based on the physical represen- 
process for the automation of the customization of the tation of the live pet. Alternatively, veterinarian services 
figurine of the present invention. may conveniently provide the equipment necessary for 3D 
The urn of the instant invention is provided with an easily 1° graphical imaging used in production of the present inven- 
accessed repository chamber for the storage of the cremation tion. One such system, the Image Data Matrix system,is 
ashes to be contained therein. The repository chamber of the described by Mechatronics PTY LTC 51 Westchester Rd. 
present invention is the inside of the decorative likeness of Malaga (Perth) Western Australia, P.O. Box 2294, Malaga 
the deceased pet without the need for any additional secur- WA 6994. 

ing or holding means such as the tube described in U.S. 15 As shown in FIG. 1, the cremated remains in this embodi- 

Patent No. 6,023,822. The repository chamber, optionally, ment are contained within the figurine representing the 

may also be contained within the decorative base/pedestal deceased pet 1. In this regard, the figurine serves both as the 

upon which the pet's statue rests, again without the need for chamber 3 for the reception of the cremated remains and as 

any additional securing or holding means that encumber and a decorative housings la. In this embodiment, the opening 

complicate access to the chamber. 20 2 for the repository chamber 3 is formed approximately at 

The chamber is conveniently accessed through a remov- the base of the neck of the statute. Access to the chamber is 

able access means or opening formed in the pet statue, such S ained b y removing the head portion 4 of the pet statue as 

as the head, neck, body, tail, leg or paw, for example. An shown in FIG 2 - The head P ortl0n 15 securely fitted by 

inconspicuous hinged door flush with the body of the known means 5, such as threaded female and male 

figurine may also be used to conceal access means located 25 adaptations, friction plug, cork, decanter, or the like. Thus, 

in the body of the pet statue. Where the cremated remains are the purchaser of the present urn may gam access to the 

to be deposited in the base upon which the statue rests, the repository chamber via the access means 2, 4, 5 without 

access means may comprise a hinged compartment behind havm S to lift or move the um. Moreover, the head portion 

which is located a slidablc compartment or drawer compris- 4 ° f the figurine is of sufficient size so that it is not difficult 

ing the repository chamber. In any case, the opening may be 30 for 6lderl y or frai] users 10 g ras P> msimpulate and remove it. 

securely sealed and, when closed, remains inconspicuous Example 2 

within the display. m „ , 

This embodiment is substantially the same as the previous 

BRIEF DESCRIPTION OF THE DRAWINGS example, except that the access means for the repository 

„„„ , „ „, . , ■ . 35 chamber 3 is located on the body 6 of the customized 

FIGS. 1-4 are profile views of various embedments of for , e oQ i]& back fa an inc icuous 

the pet urn showing access means and cutaway views of the manner ^ sfaown ^ nG 3 ^ ^ „ may bc hinged g 

sealable repository chamber. and provi<Je easy access to me repository chamber 3 without 

FIGS. 5-8 show the pet urn and supporting base member having to lift the urn. In this example as in the previous 

with views of sealable repository chambers. 40 example, the cover 9 is of sufficient size and appropriate 

design to provide easy and convenient access. In this regard, 
the hinged covering 9 need only be provided with a slight 
lifting force to reveal the repository opening 2 to the 

Example 1 chamber 3 contained there under. The hinged covering 9 is 

! 45 fitted with sealing means 15, such as a rubber stopper, on the 

In one preferred embodiment the present invention com- underside of the covering and adapted to fit into the opening 

prises a pet urn ma nufactured in the general likeness of a such that c i os ing the cover automatically engages the sealing 

particular animal species and breed in various states of means 15 into opening 2 thereby sealing the sealable cham- 

repose which is subsequently further customized upon ber3. As in the previous example, the access means 2, 9, 15 

request by the customer to the specific likeness of the animal 50 of ^ p resent invention provides convenient access to the 

whose ashes are to be contained therein. In one practical repository chamber 3. 
example of this embodiment, the urn may be manufactured 

in the likeness of the Labrador breed of dog, whereupon the Example 3 

urn maybe further customized, to bear the exact likeness of -j-^ embo diment is substantially the same as Example 2 
the deceased pet. The more particularized customization can 55 except that the opening 2 for the repository chamber 3 is 
be accomplished by matching the markings and coloration i ocate d at the shoulder 10 of the pet figurine. Removal of one 
of the urn to the deceased pet, using photographs of the of the Iegs n of the pet figurine provides access to the 
deceased or other written or verbal descriptions of the opening 2. As in Example 1, the leg 11, shown in FIG. 4a, 
features. is securely fitted by known means 5, such as threaded female 
Recent advances in technology allow production pro- 60 and male adaptations, friction plug, cork, stopper, or the like, 
cesses to be both highly automatic and at the same time Thus, the purchaser of the present urn may gain access to the 
customized. For instance, computer graphical representa- repository chamber via the access means 2, 5, 11 without 
tions of the urn to be produced can be created based on having to lift or move the um. 
photographs, verbal descriptions, or scanned images digi- 
tally superimposed on an image of an urn in the general 65 bxample 4 

likeness of the pet's species and breed. Those images then In a third preferable embodiment, shown in the FIGS, 

can be previewed by the customer and further modified to 5-8, the cremated remains are housed in a sealable reposi- 
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tory chamber 3 located in a base portion 12 of the urn. FIG. 
5 shows the customized figurine portion 16 resting on a 
pedestal -like base 12, that itself may be of any shape or size, 
and which houses a slideable drawer 13 comprising the 
repository chamber 3. In this regard, the slideable drawer 13 
provides a convenient means for accessing the repository 
chamber 3 that is independent of having to lift, move or 
disassemble the urn, particularly a heavy urn. The base 
drawer 13 in this embodiment has a sealable cover 14 for 
secure closure and keeping of the ashes. The sealable cover 
may be secured in a closed position by means 17 known in 
the arts, such as a single ball bearing and a bearing support 
mounted to the drawer wall with a concave bearing surface 
for receiving the ball bearing and a coil spring for urging the 
bearing support and ball bearing against the concave bear- 
ing. FIG. 6 shows one embodiment with a drawer 13, in the 
shape of a tube, comprising a sealable repository chamber 3 
that slides angularly into the base portion 12 of the urn. The 
side circumference of the sealable cover 14 frictionally 
engages the top of drawer housing in the base portion 12 
thereby forming the seal of the sealable repository chamber 
3. FIG. 6 also shows a closeable decorative cover 15 that 
renders the repository chamber inconspicuous within the 
urn. FIG. 6a shows the drawer of this embodiment removed 
from the base, making apparent the ease of access to the 
opening 2 of the repository chamber 3 by slideably remov- 
ing the drawer 13. FIG. 7 shows a conventional type drawer 
13 with a top 14 that sealably closes the repository chamber 
13. FIG. 8 shows the drawer inserted into a bottom portion 
of the base and a closeable decorative cover 15 to render the 
repository chamber inconspicuous within the urn. 

In any of the above examples, the repository chamber of 
the present invention may be designed to sealably accept the 
ashes of the cremated pet directly or, as they may also be 
found, in a flexible container. In addition, the present inven- 
tion may also be fitted with a durable removable rigid 
container such that the container with ashes may be securely 
transported. 

The receptacle or urn maybe made of cast material or the 
usual alloys for casting statues, such as bronze, ceramic 
material, curable resins, marble, or extrudable and thermo- 
formed plastics and the like; but is preferably of marble, or 
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most preferably of extrudable plastic. In all instances, the 
figuring portion of the urn may also be covered with a 
natural or synthetic fur, including whiskers, that may also be 
customized in length, color, and pattern representing the 
5 approximate exact likeness of the deceased animal contained 
therein. 

Although for purposes of illustration certain material and 
sizes have been defined herein, those skilled in the^art will 
recognize that various modifications to the same can be 
io accomplished without departing from the spirit of the 
present invention and such modifications are clearly con- 
templated herein. 
What is claimed is: 

1 . Aprocess for the manufacture of a pet crematory urn for 
is storing the cremated remains of a deceased pet comprising: 

(a) superimposing a digital graphical image of the like- 
ness of the deceased pet on a digital representation of 
a general likeness of the deceased pet's species, thereby 
producing a composite digital image of the deceased 

20 pet; 

(b) transmitting the composite image to a production 
facility; 

(c) using the transmitted composite digital image to 
produce the pet crematory urn wherein pet crematory 

25 urn is a replicated likeness of the deceased pet; 

(d) placing the cremated remains of the deceased pet in 
the pet crematory urn through an access means and 

(e) sealing the access means of the urn. 

2. The process of claim 1 wherein said access means is 
30 disposed in the neck portion of the replicated likeness of the 

deceased pet. 

3. The process of claim 1 wherein said access means is 
disposed in the back portion of the replicated likeness of the 
deceased pet. 

35 4. The process of claim 1 wherein said access means is 
disposed in the torso portion of the replicated likeness of the 
deceased pet. 

5. The process of claim 1 wherein said access means is 
disposed in the leg portion of the replicated likeness of the 
40 deceased pet. 
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[57] ABSTRACT 

An architecture and system loads and uses a smart card for 
payment of goods and/or services purchased on-line over the 
Internet. A client module on a client terminal controls the 
interaction with a consumer and interfaces to a card reader 
which accepts the consumer's smart card and allows loading 
and debiting of the card. Debiting works in conjunction with 
a merchant server and a payment server. Loading works in 
conjunction with a bank server and a load server. The 
Internet provides the routing functionality between the client 
terminal and the various servers. A payment server on the 
Internet includes a computer and a security module (or a 
security card in a terminal) to handle the transaction, data 
store and collection. A merchant server advertises the goods 
and/or services offered by a merchant for sale on a web site. 
The merchant contracts with an acquirer to accept smart card 
payments for goods and/or services purchased over the 
Internet. A consumer uses his smart card at the client 
terminal in order to purchase goods and/or services from the 
remote merchant server. The client terminal sends a draw 
request to the payment server. The payment server 
processes, confirms and replies to the merchant server 
(optionally by way of the client terminal). To load value, the 
client terminal requests a load from a user account at the 
bank server. A load request is sent from the card to the load 
server which processes, confirms and replies to the bank 
server (optionally by way of the client terminal). The bank 
transfers loaded funds to the card issuer for later settlement 
for a merchant from whom the user purchases goods with 
value on the card. 
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FIG. 10 



BEGIN 

' INTERNET PURCHASE BY USER WITH 
STORED VALUE CARD 
(see FIGURE 4) 



502 USER ACQUIRES AND ADDS VALUE TO A STORED-VALUE CARD 



USER ACCESSES MERCHANT SERVER WEB SITE OVER INTERNET 



USER INSERTS CARD IN CARD READER AT CLIENT TERMINAL 



USER SELECTS GOODS AND/OR SERVICES FOR PURCHASE FROM MERCHANT WEB SITE 



USER RECEIVES TOTAL SALE AND SELECTS "PURCHASE WITH STORED-VALUE CARD" 



INTERNET PAYMENT ARCHITECTURE AND SYSTEM PROCESSES ORDER 



514 USER STORED-VALUE CARD DEBITED AND USER RECEIVES 

"DEBITED" MESSAGE FROM CLIENT MODULE 



USER RECEIVES CONFIRMATION OF SALE FROM MERCHANT 
SERVER AND RECEIVES DOWNLOADED INFORMATION OR RECEIPT 
FOR GOODS AND/OR SERVICES TO BE RENDERED 



MERCHANT RECEIVES PAYMENT TO BANK ACCOUNT BY WAY OF 
INFORMATION FROM PAYMENT SERVER 
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F I Cj 1 1 A (process user purchase by system; 

8 I . ^ (see FIGURE 5) 



USER SELECTS GOODS AND/OR SERVICES FROM MERCHANT SITE AND 
REQUESTS PURCHASE WITH STORED-VALUE CARD 



MERCHANT SERVER RECEIVES REQUEST FOR 
STORED-VALUE CARD TRANSACTION 



MERCHANT SERVER SENDS PAGE OF INFORMATION TO CLIENT TERMINAL 
INCLUDING: TOTAL COST, CURRENCY, IP ADDRESS OF PAYMENT SERVER, 
TRANSACTION IDENTIFIER, MERCHANT IDENTIFIER 



608 CLIENT TERMINAL INTERACTS WITH STORED-VALUE CARD IN READER AND 
BUILDS DRAW REQUEST MESSAGE 



CLIENT TERMINAL SENDS DRAW REQUEST MESSAGE PLUS ADDITIONAL 
N INFORMATION RECEIVED FROM MERCHANT SERVER TO PAYMENT SERVER 



N 



PAYMENT SERVER PROCESSES DRAW REQUEST IN 
CONJUNCTION WITH SECURITY CARD 
(see FIGURE 11D) 



PAYMENT SERVER SENDS "DEBIT" COMMAND WITH SECURITY CARD 
\ SIGNATURE TO CLIENT TERMINAL IN ORDER FOR STORED-VALUE CARD 
TO DEBIT ITSELF 



3" 
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FIG. 11B 



CLIENT TERMINAL PASSES "DEBIT" COMMAND TO CARD WHICH 
\ DEBITS ITSELF BY TOTAL SALE AND GENERATES CARD SIGNATURE 



CARD SENDS "DEBIT SUCCESS" AND CARD SIGNATURE TO CLIENT TERMINAL 



CLIENT TERMINAL SENDS "DEBIT SUCCESS" MESSAGE AND 
CARD SIGNATURE TO PAYMENT SERVER 



PAYMENT SERVER DIRECTS RECEIVED RESPONSE TO 
SECURITY CARD IN TERMINAL 



SECURITY CARD PROCESSES RESPONSE AND VERIFIES CARD SIGNATURE 



SECURITY CARD SENDS 'CONFIRMATION" MESSAGE TO PAYMENT SERVER 



TERMINAL UPDATES ITS DATA STORE WITH CARD NUMBER, TRANSACTION 
COUNT, TOTAL SALE, RESPONSE FROM CARD, TRANSACTION NUMBERS FROM 
STORED-VALUE CARD AND SECURITY CARD, ETC. 



632 PAYMENT SERVER UPDATES ITS DATABASE WITH LOG OF TRANSACTIONS TO 
v DATE, MERCHANT IDENTIFIER, ETC. 
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PAYMENT SERVER SENDS "CONFIRMATION" MESSAGE TO CLIENT 
TERMINAL IN ENCRYPTED FORM 



CLIENT TERMINAL PASSES "CONFIRMATION" MESSAGE TO 
MERCHANT SERVER 




MERCHANT SERVER DELIVERS INFORMATION TO CLIENT TERMINAL AND/OR 
PROVIDES RECEIPT FOR GOODS AND/OR SERVICES TO BE RENDERED 



END ^~^^) 



FIG. 11C 
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FIG 1 1 D C^ ^'NSTEP6l7 ^> 



DRAW REQUEST EDITED SYNTACTICALLY AND LOGGED 



I 



DRAW REQUEST PASSED TO TERMINAL INTERFACE MODULE 



TERMINAL INTERFACE BUILDS TERMINAL SPECIFIC MESSAGE 
BASED UPON DRAW REQUEST AND TYPE OF TERMINAL 



DRAW REQUEST SENT TO TERMINAL VIA TERMINAL CONCENTRATOR 



TERMINAL PARSES DRAW REQUEST INTO COMPONENTS AND 
PROCESSES EACH COMPONENT IN TURN 



TERMINAL REACHES "DRAW AMOUNT" STATE 



TERMINAL SENDS SECURITY CARD SIGNATURE AND 
"DEBIT" COMMAND TO PAYMENT SERVER 

(^END STEP 614^) 
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BEGIN ALTERNATIVE 
COMPARISON OF STORED VALUE CARD SIGNATURE 
TO ALLOW SECURITY CARD TO RELEASE EARLIER 
(see FIGURE 6) 



PERFORM STEPS 602 - 612 AND STEPS 680 - 690 



SECURITY CARD IN TERMINAL GENERATES SECURITY CARD 
SIGNATURE, "DEBIT" COMMAND AND EXPECTED 
STORED-VALUE CARD SIGNATURE 



j70t 



TERMINAL SENDS SECURITY CARD SIGNATURE, "DEBIT" COMMAND" AND 
EXPECTED STORED-VALUE CARD SIGNATURE TO PAYMENT SERVER 



PERFORM STEPS 616 - 622 



PAYMENT SERVER CODE MODULE PROCESSES RESPONSE, VERIFIES CARD 

SIGNATURE BY COMPARING RECEIVED CARD SIGNATURE WITH EXPECTED 
STORED-VALUE CARD SIGNATURE RECEIVED EARLIER FROM SECURITY CARD 



PERFORM STEPS 632 - 640 



FIG. 12 



END ^~^^) 
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BEGIN ALTERNATIVE 
' COMPARISON OF STORED VALUE CARD SIGNATURE ^ 
BY CLIENT TERMINAL 
(see FIGURE 7) 



PERFORM STEPS 602 - 612 AND STEPS 680 - 690 



TERMINAL SENDS SECURITY CARD SIGNATURE, "DEBIT" COMMAND AND r 
EXPECTED STOR ED-VALUE CARD SIGNATURE TO PAYMENT SERVER 



I 



PERFORM STEPS 618, 620 




CLIENT TERMINAL CODE MODULE PROCESSES RESPONSE, VERIFIES CARD 
SIGNATURE BY COMPARING RECEIVED CARD SIGNATURE FROM 
STORED-VALUE CARD WITH EXPECTED SIGNATURE RECEIVED EARLIER 
FROM SECURITY CARD VIA PAYMENT SERVER 



PERFORM STEPS 636 ■ 640 



FIG. 13 
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BEGIN ALTERNATIVE 
COMPARISON OF STORED-VALUE CARD SIGNATURE 
BY MERCHANT SERVER 
(see FIGURE 8) 



PERFORM STEPS 602 - 612 AND STEPS 680 - 690 



SECURITY CARD IN TERMINAL GENERATES SECURITY CARD SIGNATURE, "DEBIT" 
COMMAND AND EXPECTED STORED-VALUE CARD SIGNATURE 



TERMINAL SENDS SECURITY CARD SIGNATURE, "DEBIT" COMMAND AND 
EXPECTED STORED-VALUE CARD SIGNATURE TO PAYMENT SERVER 



PAYMENT SERVER SENDS "DEBIT COMMAND, SECURITY CARD SIGNATURE AND ENCRYPTED 
STORED-VALUE CARD SIGNATURE TO CLIENT TERMINAL 



PERFORM STEPS 618, 620 



CLIENT TERMINAL SENDS DEBIT SUCCESS MESSAGE, RAW CARD 
SIGNATURE RECEIVED FROM STORED-VALUE CARD AND ENCRYPTED CARD 
SIGNATURE RECEIVED FROM PAYMENT SERVER TO MERCHANT SERVER 



MERCHANT SERVER PROCESSES DEBIT SUCCESS MESSAGE AND DECRYPTS 
ENCRYPTED SVC SIGNATURE IN ORDER TO COMPARE 
RAW CARD SIGNATURE TO CARD SIGNATURE FROM SECURITY CARD 



MERCHANT SERVER GENERATES CONFIRMATION MESSAGE 



PERFORM STEPS 638, 640 



FIG. 14 



U.S. Patent Aug. 15, 2000 sheet 17 of 24 6,105,008 




BEGIN IMPLEMENTATION 
OF ADDED SECURITY LAYER TO EMBODIMENTS 
OF THE INVENTION 
(see FIGURE 9) ^^^^ 




,802 



PAYMENT SERVER AND MERCHANT SERVER SHARE A 
UNIQUE DES ENCRYPTION KEY 



,804 



CLIENT TERMINAL AND MERCHANT SERVER ENGAGE IN 
PROTECTED SSL SESSION 



806 



MERCHANT SERVER DERIVES A KEY FROM THE DES KEY USING 
INFORMATION UNIQUE TO THE TRANSACTION SUCH AS MERCHANT 
IDENTIFIER, TRANSACTION IDENTIFIER, ETC. 



MERCHANT SERVER DOWNLOADS HTML PAGE TO CLIENT 
TERMINAL INCLUDING A TRANSACTION SESSION KEY (TSK) AND 
THE TSK ENCRYPTED WITH THE DERIVED KEY (ETSK) 







CLIENT SENDS DRAW REQUEST ENCRYPTED WITH TSK TO 
PAYMENT SERVER ALONG WITH ETSK 









810 



PAYMENT SERVER DECRYPTS ETSK WITH SHARED DES KEY TO PRODUCE TSK; 
DECRYPTS DRAW REQUEST WITH TSK IN ORDER TO PROCESS DRAW REQUEST, 
AND ENCRYPTS "DEBIT" COMMAND WITH TSK 



■808 



FIG. 15A 
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PAYMENT SERVER SENDS ENCRYPTED "DEBIT" 
COMMAND TO CLIENT TERMINAL 



CLIENT DECRYPTS "DEBIT" COMMAND AND PROCESSES IN 
CONJUNCTION WITH STORED-VALUE CARD 



CLIENT SENDS "DEBIT RESPONSE" MESSAGE 
ENCRYPTED WITH TSK TO PAYMENT SERVER 



^818 



PAYMENT SERVER AND SECURITY CARD PROCESS "DEBIT RESPONSE" 
MESSAGE AND SEND "DEBIT RESULT C" MESSAGE ENCRYPTED WITH TSK 
AND "DEBIT RESULT M" MESSAGE ENCRYPTED WITH DERIVED KEY TO 
CLIENT TERMINAL 
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CLIENT DECRYPTS "DEBIT RESULT C" MESSAGE AND PASSES "DEBIT 
RESULT M" MESSAGE ON TO MERCHANT SERVER 



MERCHANT SERVER DECRYPTS "DEBIT RESULT M" MESSAGE USING 
DERIVED KEY FROM DES KEY AND PROCESSES RESULT 
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USER SELECTS LOAD VALUE OPTION FROM BANK INTERNET SITE 
j 



CLIENT READS CARD BALANCE, ETC., AND SENDS TO BANK SERVER 



BANK SERVER DETERMINES MAXIMUM LOAD VALUE AND 
CHECKS FUNDS IN USER'S ACCOUNT 



\ 



BANK SERVER SENDS PAGE OF INFORMATION TO CLIENT TERMINAL 
INCLUDING: LOAD VALUE, CURRENCY, IP ADDRESS OF LOAD SERVER, 
TRANSACTION IDENTIFIER, BANK IDENTIFIER, SESSION KEY 



8 75 USER ACCOUNT DEBITED BY LOAD VALUE 
\ . _ 
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CLIENT TERMINAL INTERACTS WITH STORED-VALUE CARD IN READER AND 
BUILDS LOAD REQUEST MESSAGE 



877 CLIENT TERMINAL ACCESSES LOAD SERVER USING IP ADDRESS 

N 



878 CLIENT TERMINAL SENDS LOAD REQUEST MESSAGE TO LOAD SERVER 



LOAD SERVER PROCESSES LOAD REQUEST 
(see FIGURE 18D) 
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CARD SENDS "LOAD SUCCESS" AND CARD SIGNATURE TO CLIENT TERMINAL 



CLIENT TERMINAL SENDS "LOAD SUCCESS" MESSAGE AND CARD 
SIGNATURE TO LOAD SERVER 



LOAD SERVER PROCESSES AND DIRECTS RECEIVED 
RESPONSE TO HOST SECURITY MODULE 
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HOST SECURITY MODULE VERIFIES CARD SIGNATURE 



886 N HOST SECURITY MODULE SENDS "CONFIRMATION" TO LOAD SERVER 



LOAD SERVER UPDATES ITS DATABASE 
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870 



LOAD SERVER SENDS "CONFIRMATION" MESSAGE TO CLIENT TERMINAL 
I 



CLIENT TERMINAL PASSES "CONFIRMATION" MESSAGE TO BANK SERVER 



892 BANK SERVER REGISTERS "CONFIRMATION" MESSAGE 



END 



895 LOAD REQUEST EDITED SYNTACTICALLY AND LOGGED 



LOAD SERVER PARSES LOAD REQUEST INTO COMPONENTS 
AND PROCESSES EACH COMPONENT IN TURN 



897 — "*" LOAD REQUEST COMPONENTS PASSED TO HOST SECURITY MODULE 



HOST SECURITY MODULE VERIFIES CARD SIGNATURE, 
GENERATES SECURITY CARD SIGNATURE, "LOAD" COMMAND 



HOST SECURITY MODULE SENDS MERCHANT CARD 
SIGNATURE AND "LOAD" COMMAND TO LOAD SERVER 
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INTERNET LOADING SYSTEM USING 
SMART CARD 

This application is a continuation-in-part of U.S. patent 
application No. 08/951,614 by Davis et al., filed Oct. 16, 
1997, entitled "Internet Payment Using Smart Card" which 
is incorporated by reference. 

FIELD OF THE INVENTION 
The present invention relates generally to a value loading 
system using a computer network. More specifically, the 
present invention relates to a value loading system for a 
smart card using an open network such as the Internet. 

BACKGROUND OF THE INVENTION 
With the explosive growth in open networks (such as the 
Internet) over the past several years and the rapid increase in 
the number of consumers with access to the World Wide 
Web, there has been a great deal of interest in the develop- 
ment of electronic commerce on the Internet. Traditional 
financial transactions are being transformed. 

A technique for performing financial transactions uses a 
smart card. A smart card is typically a credit card-sized 
plastic card that includes a semiconductor chip for holding 
the digital equivalent of cash directly, instead of pointing to 
an account or providing credits. One example of a smart card 
is illustrated in FIG. 1. Of course, a smart card may be 
implemented in many ways, and need not necessarily 
include a microprocessor or other features. The smart card 
may be programmed with various types of functionality, 
such as a stored-value application; credit/debit; loyalty 
programs, etc. For the purpose of this disclosure, card 5 is 
programmed at least with a stored-valuc application, and 
will be referred to as "stored-value" card 5. 

Stored-value card 5 has an embedded microcontroller 10 
that includes a microprocessor 12, random access memory 
(RAM) 14, read-only memory (ROM) 16, non-volatile 
memory 18, an encryption module 22, and a card reader 
interface 24. Other features of the microcontroller may be 
present but are not shown, such as a clock, a random number 
generator, interrupt control, control logic, a charge pump, 
power connections, and interface contacts that allow the card 
to communicate with the outside world. 

Microprocessor 12 is any suitable central processing unit 
for executing commands and controlling the device. RAM 
14 serves as storage for calculated results and as stack 
memory. ROM 16 stores the operating system, fixed data, 
standard routines, and look up tables. Non-volatile memory 
18 (such as EPROM or EEPROM) serves to store informa- 
tion that must not be lost when the card is disconnected from 
a power source but that must also be alterable to accommo- 
date data specific to individual cards or any changes possible 
over the card lifetime. This information might include a card 
identification number, a personal identification number, 
authorization levels, cash balances, credit limits, etc. 
Encryption module 22 is an optional hardware module used 
for performing a variety of encryption algorithms. Card 
reader interface 24 includes the software and hardware 
necessary for communication with the outside world. A wide 
variety of interfaces are possible. By way of example, 
interface 24 may provide a contact interface, a close-coupled 
interface, a remote-coupled interface, or a variety of other 
interfaces. With a contact interface, signals from the micro- 
controller are routed to a number of metal contacts on the 
outside of the card which come in physical contact with 
similar contacts of a card reader device. 



)5,008 

2 

One possible use of a stored-value card by a consumer is 
illustrated in FIG. 2. FIG. 2 illustrates a block diagram of a 
customer operated service payment terminal 50. A customer 
typically uses such a service payment terminal in a face-to- 

s face environment in order to purchase goods in a store or 
directly from the terminal itself. Service payment terminal 
50 can be an attended device or it can be integrated into a 
self-service device such as a vending machine or public 
telephone. For example, the service payment terminal may 

10 be incorporated into a soda machine in order to dispense 
sodas to a customer in which the customer pays by inserting 
the stored-value card. Or, the service payment terminal may 
be a point-of-sale terminal such as is found at a check-out 
counter where a customer inserts his stored-value card in 

15 order to purchase goods. 

Service payment terminal 50 includes a router 51, a user 
interface 52, a card handler/reader 54, a security card 
handler 56, a security card 58, a terminal application 60, a 
data store 64 and a concentration point handler 66. Router 51 

20 is hardware and software for routing information between 
functional blocks. User interface 52 controls the status of 
displays on the terminal and supplies instructions to the user. 
For example, the user interface provides instructions relating 
to insertion of stored-value card 5 or security card 58. Also, 

25 the user interface provides instructions and/or buttons for the 
customer to interact with terminal application 60 in order to 
purchase goods and/or services. Card handler 54 provides a 
physical card reader and associated software for accepting 
and communicating with stored-value card 5. Similarly, 

30 security card handler 56 provides a card reader and associ- 
ated software for communicating with security card 58. In 
conjunction with security card handler 56, security card 58 
controls the command sequence of the terminal and provides 
transaction and a batch security. 

35 Terminal application 60 receives commands and informa- 
tion about the transaction and initiates the actual purchase. 
In addition, terminal application 60 is responsible for all 
application specific functionality such as guiding the cus- 
tomer through the use of the terminal via a display, and for 

40 providing all hardware and software needed to provide the 
user with a good and/or service once it has been informed by 
the security card that an appropriate value has been deducted 
from the stored-value card. 

Data store 64 controls the storage of purchase transactions 

45 and totals. Concentration point handler 66 controls the 
sending and receiving of information to and from a concen- 
tration point. Concentration point 68 is a staging computer 
that communicates with any number of service payment 
terminals to collect batches of transactions. The concentra- 

50 tion point then sends these transaction batches to a clearing 
and administration system for processing (such as in FIG. 3). 
Once processed, batch acknowledgments, along with other 
system updates are sent to the terminals via the concentra- 
tion point. The concentration point ensures a successful 

55 transfer of data between service payment terminals and the 
clearing and administration system, and prevents overload- 
ing of the clearing and administration system. The service 
provider contracts with a concentration point for collection 
of the service paymenls. The concentration point may also 

6o be an existing central facility such as a telephone company 
that collects its own payments from card telephones. 

Such a service payment terminal 50 allows a customer to 
use a stored-value card for the payment of goods and/or 
services, generates a payment result from a transaction, and 

65 bundles individual payment results into a collection for 
transfer to a clearing and administration system, which then 
transfers funds that had been debited from a customer's 
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stored-value card to the merchant whose goods and/or is disclosed that enables a smart card to be loaded with value 

services had been purchased from the terminal. on-line over an open network such as the Internet. For the 

FIG. 3 illustrates an environment 100 useful for issuing purposes of this description, a smart card with a stored-value 
stored-value cards and reconciling transactions performed application used in embodiments of the invention will be 
with such a card. A terminal supplier 102 builds the equip- 5 referred to simply as a "stored-value card." 
ment used by a service provider 104 to provide goods and/or In an embodiment of the present invention, a loading 
services to customers having a stored-value card at a service technique allows the consumer to conveniently load value 
payment terminal 50. Card Supplier 106 contracts with an on to his or her stored-value card from any suitable device 
integrated circuit manufacturer and a card manufacturer for via an open network such as the Internet. A consumer is 
integrated circuits and plastic card bodies, then embeds the io allowed to use any suitable computer at the home, office or 
integrated circuits into the cards and initializes them with a elsewhere in order to connect to his bank or other financial 
serial number. It then delivers the cards to card issuer 108. institution. Using appropriate message integrity, value is 
In conjunction with clearing and administration system 110 transferred from the bank to the consumer's stored-value 
(such as a system provided by Visa International of Foster card. At the same time, the corresponding value is trans- 
City, Calif.), card issuer 108 personalizes new cards and then 15 ferred from the bank to the stored-value card issuer through 
transfers these cards to individuals (cardholders 112). The existing networks for later settlement with a merchant from 
cardholder may then charge the card with value prior to use. whom the consumer purchases goods or services. 
Alternatively, the card may come with value already loaded. Advantageously, this embodiment makes use of an existing 
The cardholder 112 may then use the card at a service clearing and administration system for eventual settlement 
payment terminal 50 to purchase goods and/or services from 20 of the transaction between the merchant and the card issuer, 
service provider 104. Terminal 50 then debits the value from Also, the transaction is fully auditable and a log of previous 
the card, thus creating a service payment. transactions is stored on the card for later display. Thus, a 

Periodically, all transactions are sent in a data file from consumer may conveniently load value on to his or her card 

terminal 50 via concentration point 68 and an acquirer 114 while a high level of security is maintained and the card 

to clearing and batch administration system 110 along with 25 issuer can take advantage of unspent funds on the card, 

accumulated service payment batches from other terminals. From the consumer's perspective, the present invention 

Based upon this collection data, clearing and administration operates in a fashion similar to loading a stored-value card 

system 110 then receives money from card issuer 108 which at an ATM machine, except that the consumer need not insert 

had originally come from cardholder 112. Clearing and cash or an additional debit or credit card, nor need travel to 

administration system 110 then transfers a lump sum to 30 a bank. The loading functionality is distributed across the 

acquirer 114 using a suitable settlement service (such as one Internet between the card reading device located where the 

provided by Visa International) to pay the various service customer is, a bank server holding the consumer's account, 

providers having a relationship with acquirer 114. Based and a load server with a host security module that provides 

upon the previous collection data, acquirer 114 then trans- security. All of these entities may be physically remote from 

fers an appropriate amount of money to each service pro- 35 one another with router functionality being provided by the 

vider 104 reflecting the value of the goods and/or services Internet. 

that thai service provider had provided that day to cardhold- From the consumer's perspective, the present invention is 

ers based upon deductions from their stored-value cards. eas y to use. A consumer need not establish a new relation- 

Thus as described above, a variety of goods or services 4Q ship with a bank or other Internet service company, nor 

may be purchased using a stored-value card from a merchant create a special Internet deposit account in order to load 

having a terminal 50, or over the Internet using a technique value onto a stored-value card over the Internet. A consumer 

such as described in U.S. patent application No. 08/951,614 simply makes use of his or her bank account and currently 

referenced above. available stored-value cards in order to load value using any 

However, in order to purchase, the card must be loaded 45 conveniently available computing device with a card reader 

with value first. Value can be loaded onto a stored-value card and Internet access. 

in a variety of ways. Currently, it is inconvenient for a user In addition, once value has been loaded onto the stored- 

to load value onto his or her stored-value card. A user must value card, an existing clearing and administration system is 

physically travel to a bank or other institution that has an used to reconcile the transaction and to pay the appropriate 

automated teller machine (ATM) or other similar device in 50 parties once the value has been spent. Advantageously, a 

order to load value on to his or her stored-value card. The new system and methodology for reconciling transactions 

user can insert money into the machine and have a corre- need not be developed or implemented. The pre-existing 

sponding value put onto the stored-value card, the user can clearing and administration system is used which greatly 

use a debit card to deduct value from the user's account at simplifies implementation of the present invention. A par- 

the bank for transfer to the card, or a credit card can be used 55 ticipaling bank need not implement or become familiar with 

as the source of funds to be transferred to the stored-value new procedures for reconciliation of transactions, 

card. In either case, the user must travel to the bank to load Furthermore, a bank need only make a minimal invest- 

value. Further creating difficulty is that not all banks or other ment in tj me ^ money to take advantage of the present 

financial institutions have such a machine for loading value invention in order to allow its customers to load value from 

onto a user's stored-value card. 60 tDeir ex i stm g accounts over the Internet. The bank need not 

Accordingly, it would be desirable to have a technique to engage in the development of complex custom software or 

allow a user to conveniently and easily load value onto a accounting procedures. By incorporating software libraries, 

stored-value card. a bank is ready to begin loading value onto its customer's 

„ cards from its web site. Preferably, libraries are provided that 

SUMMARY OF THE INVENTION fi5 i[Uerface with an exjsting ^ at a bank tQ the 

To achieve the foregoing, and in accordance with the building of an HTML page. Because a smart card with a 

purpose of the present invention, an architecture and system stored-value application is used, the bank server, load server 
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and client terminal perform the details of the transaction and FIG. 3 is a block diagram of an example of a clearing and 
the bank itself is relieved from having to control and keep administration system useful for reconciling financial trans- 
track of a transaction. Also, the load server and stored-value actions received from a service payment terminal, 
card manage and provide security for the transaction. I.e., FIG. 4 illustrates an architecture and system for payment 
the bank need not be concerned about security nor be s Qyer ^ InIerne , usi a slored . value card 

responsible for authenticating a stored-value card nor for . .„ ° , ,. 

determining a balance on the card. Of course, a load server . FIG ; 5 illustrates a payment embodiment of the present 

could coexist alongside the bank server or could even be the invention. 

same computer. That is, a bank could implement load server FIG. 6 illustrates another payment embodiment of the 

functionality at its own site if it so desired. In a preferred 10 present invention in which the security card releases earlier, 

embodiment, the load server and its security module is FIG. 7 illustrates yet another payment embodiment of the 

provided by a separate financial institution or by a third- present invention having fewer round trip messages between 

party processor. the client terminal and payment server. 

The present invention also provides benefits to issuers and FIG. 8 illustrates still another payment embodiment of the 

acquirers. Expansion of the functionality for a stored-value js present invention in which the merchant server compares 

card increases revenue opportunities from cardholders and stored-value card signatures. 

merchants. In addition, in one specific embodiment of the FIG. 9 illustrates an added encryption layer useful for 

invention, funds that are loaded onto a card are transferred embodimerits of the present invention, 

from the loading bank to the card issuer so that the issuer . 

may take advantage of the funds on the card until they are 2Q . f 3 « owcnart descn 

spent a stored-value card purchas 

The present invention is suitable for use with any type of m ™^° B ',. „^ . 

stored-value card that is able to store an amount and to load , FIGS - UA-11D are a flowchart describing the processing 

a value upon a command. In one embodiment of the of a ^ P urchase usm S an embodiment of the present 

invention, a stored-value card implemented as a processor 25 inventIon - 

card works well. Use of a processor card has advantages FIG. 12 is a flowchart describing the alternative embodi- 

where information processing is done on the card rather than ment °f FIG- 6 - 

in the terminal or host computer. Processor cards allow FIG. 13 is a flowchart describing the alternative embodi- 

encryption to be done by the card, allow generation of ment of FIG. 7. 

signatures, and can accommodate multiple passwords or 30 FIG. 14 is a flowchart describing the alternative embodi- 

pcrsonal identification (such as biometrics that uniquely ment 0 f p\Q g 

identify the holder of the card). Processor cards also provide FI(JS , 5Aand lgB afe a flowchar , describ ; [n6 added 

increased data security, an anti-fraud capability, flexibility in secur j tv [ ayer of FIG 9 

applications, a multi-purpose capability, and off-line valida- ,. 

lion. Because high telecommunication costs and/or low 35 . FIG. 16 illustrates an architecture and system for authen- 

reliabihty of a network may make on-line authorization tlcatlon over an internet usln S a ^red-value card, 

impractical, a stored-value card with the capability for FIG. 17 illustrates a system for loading value onto a 

performing off-line processing and authentication by itself is stored-value card according to one embodiment of the 

extremely valuable. present invention. 

In another embodiment of the present invention, a con- 40 FIGS. 18A-18D are a flowchart describing the loading of 

sumer may wish to access any of a variety of Web servers in a consumer's stored-value card using an embodiment of the 

order to load frequent flyer miles, award points, etc., that he present invention. 

or she has accumulated. In this embodiment, a consumer has FIG. 19 is a block diagram of a typical computer system 

accumulated points through any of a variety of programs suitable for use in embodiments of the present ir 

with airlines, restaurants, rental car companies, hotels, 45 
banks, credit or debit card issuers, telephone or other com- 
munication companies, etc. These points are stored by the 

particular airline, etc., that has issued them. The consumer nPNFRAT ARrwrFr-niRP 

wishes to load these points onto his or her stored-value card GENERAL ARCHITECTURE 

in order to redeem them elsewhere; thus receiving airline 50 The present invention separates the functionality involved 

tickets, meals, car rental, overnight stays, prizes, awards, in a transaction using a stored-value card in order to take 

discounts, or other benefits. By accessing an Internet server advantage of the routing capabilities of the Internet. FIG. 4 

associated with the particular program, the consumer is able illustrates symbolically an architecture 200 for an internet 

to load his or her stored-value card in any of the embodi- payment system involving a smart card, such as a smart card 

ments described herein to receive the benefits of the 55 having a stored-value capability. An internet loading system 

program, much in the same way that currency is loaded. is shown in FIG. 17 and may have similar functionality as 

„„„„ nrt .nmnTin»r toe t->d a«7ixt^c described below. Shown is an internet 202, a client terminal 

BRIEF DESCRIPTION OF THE DRAWINGS , , , , _ AO , , 
204, a payment server 206 and a merchant server 20s. Local 

The invention, together with further advantages thereof, cardholder functions including a consumer card interface, 

may best be understood by reference to the following 60 disp i ay and accept/cancel options are performed at client 

description taken in conjunction with the accompanying terminal 204. Payment functions including security card 

drawings in which: control, data store and use of a concentration point are 

FIG. 1 is a block diagram of an example of a stored-value performed by payment server 206. The presentation and 

card useful in embodiments of the present invention. eventual delivery of goods and/or services by a merchant are 

FIG. 2 is a block diagram of a service payment terminal 65 performed under control of merchant server 208. The inter- 
in which a stored-value card may be inserted to purchase net 202 performs routing functions between each entity. It 
merchandise. should be appreciated that internet 202 may take the form of 



the Internet currently in use, or may also be any other open 
network implemented using any combination of computer, 
telephone, microwave, satellite, and/or cable networks. 

Basically, client terminal 204 controls the interaction with 
a user and interfaces to card reader 210 which accepts a 5 
smart card having a stored-value application. For simplicity, 
throughout the remainder of this specification, card 5 will be 
referred to as a stored-value card (SVC) 5. Payment server 
206 communicates directly with a terminal or through a 
concentrator 212 that handles any number of terminals 10 
214-216 each having a security card 218 and 220 respec- 
tively. Payment server 206 also communicates with concen- 
tration point 68 for transmission of transaction data to a 
clearing and administration system. Database 223 stores all computer a 
suitable information passing through payment server 206 for « ^ P^ ^ f ^ 
each transaction. Use of such a database allows any number 
of merchants (or merchant servers) to use payment server 
206 for transactions. Payment server 206 controls payment 
functions such as handling the attached terminals, managing 
data base 223 and collection functions. Merchant 
is a site that has contracted with an acquirer to accept 
stored-value card transactions as payments for goods and/or 
services purchased over the Internet. 

Stored-value card 5 may take a variety of forms and is 
useful in many situations where it is desirable to store 
monetary value on a card that a consumer may use. In 
general, a stored-value card is any card or similar device that 
is able to store a value that is decremented when the card is 
used. The card may be purchased complete with a stored- 
value or value may be later added to the card by a user. Such 
cards may also have their value replenished. Of course, a 
stored-value card need not be in the form of the traditional 
credit card, but could appear in any form and of any material 
that is able to store value and be manipulated by a user for 
a payment transaction. By way of example, other forms that 
a stored-value card may take are any electronic representa- 
tions. Further, the functionality of stored-value card 5 may 
be implemented in software on client terminal 204, that is, 
card 5 may be a "virtual" card. 

A stored-value card may also perform a variety of func- 
tions in addition to simply storing value. A card may be 
dedicated to the storing value or may contain memory and 
programs for other applications as well. By way of example, 
an "electronic wallet" refers to a processor card that can 



numbers, biometrics, simple algorithms, or sophisticated 
algorithms such as the Data Encryption Standard (DES) or 
Rivest, Shamir, Adelman (RSA) encryption. The card is thus 
able to use these precautions to verify users, card readers, 
etc., to validate security cards and/or to provide a unique 
signature. Preferably card 5 includes any number of keys 
known to the card issuer that are used during the course of 
a payment or load transaction to generate signatures for 
validation of the stored-value card, validation of the security 
card or module, and validation of the system itself. 

Client terminal 204 is any suitable device for interacting 
with a stored-valued card 5 and for communicating over a 
network to a payment server or a merchant server. By way 
of example, client terminal 204 may be a mainframe 
work station, a personal computer, a kiosk, or 
any type of service payment terminal that a consumer might 
use to purchase goods and/or services. Furthermore, client 
terminal 204 may also be embodied in any portable device 
such as a laptop computer, a cellular telephone, or any 
208 20 variet y °f a personal digital assistant (PDA) such as those 
made by Apple Computer, Inc. or by U.S. Robotics. Card 
reader 210 is any suitable interface device that functions to 
transfer information and commands between client terminal 
204 and stored-value card 5. By way of example, card reader 
210 may be a card reader manufactured by Fischer-Farr 
International of Naples, Fla., by Hewlett-Packard of Palo 
Alto, Calif., by Schlumberger, by Gem Plus, etc. Card reader 
210 may take any variety of forms such as a stand alone unit, 
integrated with the client terminal, attached to the keyboard 
of the client terminal, or even built in to a floppy disk-sized 
unit capable of being read from a disk drive of the client 
terminal, etc. 

Client terminal 204 includes client code module 224 and 
card reader module 226. Reader module 226 may be imple- 
mented using any suitable software and libraries for com- 
municating with card reader 210 and its actual implemen- 
tation will depend upon the type of card reader used. Client 
module 224 controls communication between the client 
terminal, the card reader, the payment server and the mer- 
chant server. Client module 224 may be implemented using 
any suitable code. In one embodiment of the invention, 
client module 224 is implemented using a combination of 
"C" code and a Java applet. The applet is also supplemented 
with parameters from an HTML page sent from the n 



chant server. It is contemplated that Java code works well for 

execute a variety of financial transactions and identification implementing the modules on the client, payment and mer- 

functions. Such a card may serve debit, credit, prepayment, chant servers because it is platform independent, and could 

and other functions. A stored-value card typically includes ev6n replace the "C" and "C++" code used, 

information such as a bank identifier number, a sequence Client module 224 is also responsible for controlling 

number, a purchase key, a load key, an update key, an 5Q disp i ays to the user an d for the interaction between the card 

expiration date, a transaction counter, a session key, etc., in and tne card reader The module also builds the draw request 

addition to a running balance. message after receiving all of the start-up information from 

A stored-value card may also be termed a prepayment the card and the amount of the purchase from the merchant 

card, a cash card, or a decrement-in-value card. A stored- server. The client module is able to communicate with all 

value card may also be implemented by using a variety of S5 components on the Internet, either directly or indirectly, 

card technologies. By way of example, a stored-value card Payment server 206 includes payment code module 228 

typically implemented as a card containing one or more atK j terminal interface 230. As with client terminal 204, 



integrated circuits. One example of an integrated circuit card 
is a memory card that has a semiconductor device for storing 
information but lacks calculating capability. Another 6 
example of an integrated circuit card is a processor card that 
has not only memory but also a microcontroller to enable the 
card to make decision. Aprocessor card may also be termed 
a microprocessor card or a "smart card". 

A processor card may include an encryption module in 6 
order to provide a variety of security precautions. By way of 
example, security precautions may include simple PIN 



payment server 206 may be implemented using any suitable 
computer. By way of example, a personal computer works 
well. There may be one payment server for each merchant 
server or a single payment server may service any number 
of merchant servers. Alternatively, there may be multiple 
payment servers for a single merchant. In addition, payment 
server 206 need not be remote from merchant server 208 but 
may be located at the same site and have a different Internet 
address, or the payment server and the merchant server may 
even be implemented on the same computer. Payment server 
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206 is designed to facilitate the communication between the transactions. The concentration point then sends these trans- 
user's stored-value card and a terminal's security card. If a action batches to a clearing and administration system for 
part of a transaction fails to complete, the payment server processing. Once processed, batch acknowledgments, along 
may notify the participating system components. with other system updates, are sent back to the terminals via 

Payment module 228 may be implemented using any 5 the concentration point, 

suitable code. By way of example, payment module 228 is Merchant server 208 includes a merchant code module 

implemented using a combination of C code, C++ code 2n Mereham 208 may be implemented upon any 

and Java code. Payment module 228 is, in one specific com f c ^ rnmun f cat i n ^ £ nd 

embodiment, a multi- threaded process tha' cj» «v« mul- & information £ users over an internet. Merchant code 

tiple concurrent client applet transactions on demand, lne , n , „„- , , , . , , 

module is responsible for controlling all interactions with 10 module 232 m ^ b * ™plemented using any suitable code, 

the terminals and their concentrator including the transaction B y wav of example merchant module232 may be imple- 

collection function. For individual transactions, the payment ™ Dl f a ambulation of Perl, HTML, and Java code. 



Merchant server 208 is typically a generic web s 
for the merchant's business. Merchant si 



module controls the message flows and logs interim results. 

When an applet connects with the payment server, it creates , 

t tu „„a t„ o„™™ t .i,. t,,™,-.;™ .i,™.™!, .to 1 jr. 208 may include databases, CGI scripts and back-office 

a transaction thread to support the transaction through its life ... . tttwt c t. 

cycle. Each thread, in turn, assigns a terminal for commu- programs that produce HTML pages for an Internet user, 

nication. Having a one-to-one correspondence between A brief discussion of the flow of a transaction now 

transaction threads and terminals has been found to provide follows. During a financial transaction, the client terminal 

desirable results and merchant server exchange information 234 via internet 

Terminal interface 230 is any suitable set of software and 2 ° 202 Each transaction initiated by a user has a transaction 
libraries for communicating with a terminal 214 either identifier created at the merchant server, and a merchant 
directly or, as shown, through terminal concentrator 212 . identifier unique to the payment server is also available from 
The actual implementation of terminal interface 230 will the merchant server. Client module 224 and the payment 
depend upon the type of terminal used. A terminal such as server also ^ um 1 ue transaction identifier for tracking 
214 may be any suitable terminal such as are known in the and lo && n & information about the transaction. Merchant 
art. By way of example, an iq Delta 2010 terminal made by S6rver 208 generates a unique identification of the 
Schlumberger has been found to provide desirable results. transaction, completes other required parameters, encrypts 
Such a terminal may support a variety of commands origi- as appropriate, and builds an HTML page and sends it to the 
naling from the terminal interface. These commands emu- 30 client terminal. The client module interacts 235 with the 
late the normal responses that an attached terminal would stored-value card and builds a draw request message con- 
pass from the stored-value card to the security card. The tamin g relaled card information, the purchase amount, and 
actual security card commands are held in the terminal while ° lher information supplied by the merchant server, 
the terminal performs the tasks necessary to simulate the The client terminal then communicates 236 with payment 
presence of a stored-value card. 35 server 206, first by forwarding the draw request to the 

Security card 218 may be any suitable security card such payment server. Payment server 206 verifies the transaction 

as are known in the art (often referred to as a Purchase to determine if it is a valid transaction from a known 

Secure Application Module— PSAM). In other merchant. The transaction is logged into the payment serv- 

embodiments, the functionality of security card 218 can be er's transaction database 223. Upon completion of a 

replaced by a hardware security module, could be imple- 40 transaction, payment server 206 builds a result message 

mented in hardware within the payment server, or could containing the identification of the transaction and signs it. 

even be implemented in software. The message is then routed to merchant server 208 via client 

By way of example, security card 218 is a removable terminal 204 - Merchant server 208 then validates the result 

credit card-sized processor card that is programmed to message. After determining that the transaction was 

process and store data relating to financial transactions. 45 successful, merchant server 208 creates an HTML page for 

Security card 218 contains a microchip embedded in the the Purchased information and sends it to client terminal 

card that enables the security card to authenticate and to 204 Alternatively, the merchant may also deliver purchased 

validate the user's stored-value card. If a user stored-value g oods to the user at thls P olnt - u IS also P osslWe for the 

card is accepted by the security card, and the stored-value payment server and the merchant server to communicate 

card contains sufficient value, the security card guarantees 50 ^formation 238 directly between themselves. Preferably, as 

that the merchant providing the goods and/or services cUent terminal 204 has already established commumcation 

receives payment according to the amount deducted from with ,he merchant server and the payment server, links 234 

the stored-value card for the goods and/or services rendered. and 236 are used lo exchange information between the 

In a preferred embodiment, the security card also contains payment server and the merchant server, rather than estab- 

DES purchase security keys and authenticates the stored- 55 llshlr| g a new llnk 23S - 
value card during a purchase transaction and secures the 
payment and collection totals. A security card also stores 
signature algorithms for stored-value cards in use. A security 

card may also contain a transaction identifier for the current FIG. 10 is a flowchart describing an embodiment of the 

transaction, a financial sum of all transactions remaining to 60 present invention from a user's perspective such as may 

be settled, a session key, and master keys for all stored-value occur with the embodiment of the invention shown in FIG. 

cards in use. Further, the security card may contain genera- 4. In step 502, a user acquires and adds value to a stored- 

tions of keys, blocked card indicators, date of last update, value card. Alternatively, a user may acquire a stored-value 

multiple card programs, different currency rates and addi- card that already contains value. This stored-value card may 

tional security. 65 take the form of any of the above-described stored-value 

Concentration point 68 is a staging computer that com- cards that are able to store value and to debit value from the 

municates with terminals to collect batches of purchase card. In step 504 the user accesses the merchant server web 
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site via communication link 234 over the Internet. This In step 606 the merchant server builds an HTML page that 

access of a web site may be performed in any suitable includes the following client applet parameters: the total cost 

fashion such as by using any commercially available web of the transaction as determined by the merchant server; the 

browser. In step 506 the user inserts a stored-value card in type of currency being used; the port and IP address of the 

card reader 210 at the user's terminal. Alternatively, the user s payment server; a unique transaction identifier used by both 

may insert the card before accessing the web site, or even me payment server and the merchant server to track a 

after the selection of goods and/or services from the mer- transaction; and a unique merchant identifier assigned to the 

chant web site. In step 508 the user browses the merchant me u rchan ! b V the acquirer and known to the payment server, 

web site and selects goods and/or services for purchase from ° ther ^formation may also be included such as the curren- 

the merchant using the web site interface that the merchant to «* */*P°™*> a stat » s URL address of the merchant server 

u -j j tl .l i . • . u used E° r communication from the client terminal, and a 

has provided The user then selects an appropriate button on merchan{ gerieraled key and other security informa . 

the merchant web site to indicate what the user wishes o ^ tQ en&ure ^ ^ ^ merchant ^ ^ ^ 

purchase Next, in step 510 the user receives a total sale integrity of the message . other process related information 

amount from the merchant server and is directed to actuate such ^ sofrware release ]evelj encryption methodology and 

a button on the web site indicating that the user wishes to is keys may also be conveye d. Once this page has been built, 

proceed with the purchase using the stored-value card. the page is sent 306 to the requesting client browser and 

In step 512 the architecture and system of the present triggers the loading of the client code module (in this 

invention (such as is shown in FIG. 4, for example) pro- example a Java applet) in the client terminal, 

cesses the user order by way of the payment server, terminal Some browsers may not allow an applet to invoke a 

and security card. In step 514, the user's stored-value card 2° dynamic link library (DLL) due to security reasons. In an 

is debited by the total sale amount and the user receives a embodiment of the present invention, the client applet along 

"debited" message at the user's terminal. This message is with any DLLs needed are preloaded on the client terminal, 

optional if the system is designed so as to not inform the user toe merchant server is allowed to invoke the client 

of this debit. In step 516 the user receives a confirmation a PP let and °LLs dynamically to circumvent this security 

message from the merchant server indicating that the trans- 25 P recautl0IL 

action has been completed. The user may now download the In step 608 the client module of the client terminal 

purchased information and/or receive a receipt for goods jj^racts with stored-value card 5 to obtain card information 

and/or services to be rendered or delivered from the mer- 308 ln . order ,;° bmld a *"» request message for later 

chant at a later date. In step 518 the merchant, via a clearing transmission 310 to payment server 206. In one embodiment 

and administration system, receives payment to its bank *> the invention, the client applet loads a local DLL, makes 

it for the goods and/or services rendered by way of arj ** 1 " ll T l ° thal , wluch » mm u mak « a « n \° 

.? - - . 1 - 1 annthAr HI I that finallv malff>c 9 r-M In th*. nsrA rpidpr Tn 



• t „„• , . tr . another DLL that fmallv makes a call to the card reader. Ii 

information collected from the payment server. In one .-. 

embodiment of the invention, an existing clearing and thls fashi0 ? communication with the card is achieved Once 

administration system is used, as well as an existing mcth- responses from the card are received the client module will 

odology for transferring information from a security card for 35 also combine these res P on f s ,nto a b y te stream s " ltable [ or 
- • — iransmissmn over a network to a payment server. Also at i his 



later reconciliation. This use of an existing "back end" - 
allows systems of the invention to be implemented quickly pomt, the currency type and expiration date o, 

- - • checked, and the total cost of the ordered merchandise is 



and cheaply. This approach also ensures that cards used in 



the system are compatible with other stored-value terminals. checked against the card balance to ensure that the value on 
40 the card is great enough to cover the transaction. If the 

DETAILED PAYMENT TRANSACTION FLOW checks are 1X51 successful, a message to that effect is deliv- 
ered to the user and this transaction terminates. 

FIG. 5 illustrates a detailed embodiment of internet pay- ^ client mo d u le emulates a variety of security card 

ment architecture 200 having client terminal 204, payment commands to receive responses from these commands from 

server 206 and merchant server 208. A stored-value card 5 45 t he stored-value card. Because the stored-value card and the 

is in communication with client terminal 204, and a security seCT i r ity card are now physically separated from one another, 

card 218 inside a terminal 214 is in communication with and communication takes place over the Internet, it would 

payment server 206. Not shown for simplicity in this figure not be advantageous to engage in numerous commands and 

are other elements of the system shown in FIG. 4. One responses over such an open network. In the interest of 

embodiment of a technique by which a financial transaction 50 speef j and reliability, it is advantageous to have fewer 

may be completed over the Internet will now be described messages exchanged '. 

using the flowchart of FIGS. 11A through 11D with refer- Xo operate se cu re ly an d reliably in this environment, in 

ence to FIG. 5. one embodiment of the present invention, client module 224 

It should be appreciated that a wide variety of terminol- emulates a security card and gathers all the responses for 

ogy may be used to describe message flow throughout the 55 transmission in one draw request message. The draw request 

architecture. For example, the terminology used herein to message may include a variety of information including a 

describe the sequential messages draw request, debit, draw request token, state information, the merchant 

success, and confirmation, may also be referred to by the identifier, the transaction identifier, security information, a 

respective terminology: draw request, debit IEP, debit purS e provider identifier, an intersector electronic purse 

response, and debit result (or message result). 6 o (IEP) identifier, an algorithm used by the card, an expiry 

Initially, a suitable web browser of client terminal 204 is date, the balance of the card, a currency code, a currency 

used by the user to access a merchant server web site as exponent, the authentication mode of the IEP, the transaction 

indicated by 302. In step 602, the user selects goods and/or number of the IEP, a key version and the purchase amount, 

services from the merchant site and indicates to the site that As all of this information is prepackaged into a single draw 

the user wishes to purchase these items using a stored-value 65 request message, the number of messages between the 

card as indicated at 304. In step 604 the merchant server stored-value card and the security card over the Internet is 

receives this request for a stored-value card transaction. greatly reduced. 
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In this embodiment, the draw request message is built by amount has been deducted from the balance on stored-vahie 

packaging the stored-value card's response to the "reset" card 5. Next, in step 622, client module 224 packages the 

and "initialize" commands and any public key certificates success message along with the card signature and sends 

along with the total cost and the currency of the transaction them back to. payment server 206 as indicated at 322. Client 

received from the HTML page. For public key cards, the 5 module 224 also logs the result of this stored-value card 

card and issuer certificates are obtained from read com- debit. 

mands and may also be included in the draw request. By j n slep 624 the payment server receives incoming mes- 

packaging all of this information together into one draw sa g e 322 and creates a log and updates the transaction status 

request message, it is possible to cut down on the number of m database for future error recovery. The payment server 

messages exchanged between the client server and the 10 then directs this received message to the security card in the 

payment server, and reliability and speed is improved. In one terminal as indicated at 324. Next, in step 626 the security 

embodiment of the invention, an intersector electronic purse car£ j processes this response from the client's terminal and 

(IEP) protocol is used to reset and initialize the card and to verifies the received stored-value card signature, 

receive a response. ^ the secur jty car d contains the keys and algorithms 

Next, in step 610 the client terminal accesses the payment 15 necessary to compute stored-value card signatures, the secu- 

server using the IP address received from the merchant rity cart j ^ aD l e to validate that a received stored-value card 

server. In step 612 the client terminal sends the draw request signature is in fact a valid one by comparing this stored- 

message to the payment server as indicated at 310. The client va i ue car( j signature with a generated expected value. A 

terminal also creates a log of this message being sent. successful comparison indicates that a success message 324 

In step 614 the payment server processes the draw request 20 received from the stored-value card is in fact a valid success 

in conjunction with an associated security card as will be message and that the stored-value card has been debited. An 

explained in greater detail below with reference to FIG. 11D. error result code or a comparison that is not successful 

Draw request 312 is shown being sent to terminal 214. In potentially indicates that the stored-value card has not been 

one embodiment of the invention, the payment server ere- debited by the proper amount. This comparison of stored- 

ates a transaction thread for each connected client module to 25 value card signatures by the security card ensures that a 

service it through the life cycle of the transaction. After step stored-value card is in fact debited before the merchant 

614, the payment server has received a debit command and server is directed to release the purchased merchandise. This 

a security card signature 314 from the security card in the comparison of the stored-value card sign?.(ure to an expected 

terminal. This debit command may also be termed a "debit value is performed by the security card for the highest level 

IEP" command. The security card signature is a value that 30 of security. As will be described in the embodiments of 

uniquely identifies and validates security card 218 to prove FIGS. 6, 7, and 8, this comparison of stored-value card 

to stored-value card 5 that the incoming debit command is signatures may also take place in the payment server, in the 

a valid command from a real security card. This validation client terminal or in the merchant server with a variety of 

ensures that when the stored-value card is debited, that the other advantages. Assuming that the transaction is so far 

financial totals in the security card are updated. Thus, the 35 valid, in step 628 the security card sends a "confirmation" 

user of the stored-value card is guaranteed that a valid debit message back to the payment server as indicated at 326. This 

of the card has occurred. In a preferred embodiment of the confirmation message may also be termed a "message 

invention, the security card signature is an encrypted value result." 

ensuring that no other entity can forge an identity of a ^ i n step 630 the terminal updates its data store with the 

security card. stored-value card number, a transaction count, the total sale 

In step 616 the payment server sends the debit command amount, the response from the security card, and transaction 

along with the security card signature to the client terminal numbers from the stored-value card and from the security 

as indicated at 316 for the stored-value card to debit itself. card. The payment server also logs the response received 

At this time, the payment server also logs this debit com- 45 from the terminal including the merchant identifier, etc., as 

mand into its database. indicated in step 632. Next, in step 634, the payment server 

In step 618, upon receiving the debit command from the creates a confirmation message including the transaction 
payment server, the client module replaces the amount in the identifiers and sends this message to the client terminal in 
debit command with the original amount (from the merchant encrypted form as indicated at 328. This message 328 may 
server) to ensure that the amount has not been tampered with 50 also be termed a "message result." 
while traveling over the network. At this time, the client By sending this confirmation message in encrypted form, 
module also creates a log of the debit command. Client the confirmation message may be passed to the merchant 
module 224 then passes 318 the debit command and security server by way of the client terminal without fear of tamper- 
card signature to stored-value card 5 which verifies the ing. As the confirmation message is encrypted, it would be 
signature, debits itself by the purchase amount, and also 55 extremely difficult for the client terminal or another entity to 
generates a success message (also termed a "debit response" forge a confirmation message and trick the merchant server 
message) and a stored-value card signature. The stored- into thinking that a transaction had taken place. In another 
value card signature is a unique value identifying a valid embodiment of the invention, if the client terminal is a 
stored-value card. In a preferred embodiment of the trusted agent, then the confirmation message need not be 
invention, this signature is in encrypted form to prevent 60 encrypted. In yet another embodiment, the payment server 
tampering. If card 5 does not have enough value to satisfy may sent two confirmation messages, one not encrypted for 
the purchase amount, then the "debit response" message the client to process, and one encrypted for the merchant 
indicates as such. server. FIGS. 15A and 15B present an embodiment in which 

In step 620, card 5 sends a success message 320 along the payment server sends two messages to the client termi- 
with the card signature back to client module 224 in client 65 Mi- 
terminal 204. This success message may also be termed a At this point, the transaction thread of the payment server 
"debit response" message. At this point, the purchase that was used for the current transaction may release the 
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terminal, thus allowing the terminal to be used by other in fewer exchanges over the Internet between the client 

transactions. This transaction thread then exits at this time. terminal and the payment server. By now simulating an 

In step 636 the client terminal then passes this conflrma- interaction, the security card behaves as if it were in a 

tion message 330 on to the merchant server at the URL physical terminal along with the stored-value card. Avariety 

address previously received from the merchant server. Mes- 5 °f responses from a stored-value card may be emulated. In 

sage 330 may also be termed a "message result." The client this embodiment, the terminal sends each of the three 

may also post a message to the user informing that the debit packages "answer to reset", "initialize IEP", and "debit" 

has been completed. The client also logs confirmation of the down to the security card individually and waits for a return 

payment. In step 638 the merchant server registers this message before sending the next response. For a public key 

confirmation message and checks for success. The merchant 10 transaction, the certificates read by the client are also 

server calls a validate routine within the merchant code included as individual responses. In this fashion, even 

module with the confirmation message in order to validate though all of the stored-value card information (the draw 

the response from the client. The validate routine is able to request) originating from the client terminal has been sent at 

take the transaction identifier along with the encrypted once m prepackaged form over the Internet, the traditional 

confirmation message to decrypt the confirmation message. 15 interaction between the stored-value card and the security 

If the decrypted confirmation message is acceptable, the card i n a physical terminal may be simulated at the terminal 

merchant server then determines a successful transaction has m a remote location. 

occurred. Next, in step 640 the merchant server generates an In step 690 the terminal reaches a "draw amount" state, 
HTML page with the purchased information and delivers indicating that the security card is able to generate a debit 
this information to the client terminal. Alternatively, the 20 command. In step 692, the security card generates its 
merchant server may generate a purchase receipt to deliver security card signature and the debit command. The debit 
to the client terminal indicating goods and/or services to be command may also be termed a "debit IEP" command. This 
rendered. At this point, the client terminal may also log the signature and debit command 314 are sent to the terminal, 
merchant server's response. Completion of these steps indi- The debit command issued by the security card may contain 
cates a successful financial transaction over the Internet 25 a wide variety of information including the security card 
using a stored-value card. identifier, the transaction identifier, the amount to be debited, 
Returning now to a more detailed discussion of step 614, the currency and currency exponent for the amount, the 
FIG. 11D describes one technique for processing a draw security card signature, the date, time, and location. The 
request message in conjunction with a security card. Once terminal in turn, sends the signature, command, and the 
this draw request message has been received by the payment 30 terminal identifier to the payment server as indicated in step 
server and passed along to the terminal, the terminal parses 694 The information may be sent to the payment server as 
the message back into individual responses and passes these indicated at 314 via a concentrator. At this point, step 614 
responses sequentially to the security card as will be ends and control returns to step 616. 
explained below. In an alternative embodiment, a dumb 
terminal is used and the draw request is parsed into its 35 
components and otherwise processed by the payment server, 
which then sends the responses to the security card itself. FIG. 6 illustrates an alternative embodiment 200a in 
In step 680 the payment code module of the payment which the security card is able to be released sooner than the 
server edits the draw request for syntactic correctness and w security card of FIG. 5; this embodiment also requires fewer 
logs the draw request message as being received. In step 682 exchanges between the terminal and the payment server. A 
the draw request is passed to the terminal interface module security card in a terminal is dedicated to a particular 
of the payment server. In one specific embodiment, the transaction from the moment when the terminal interface 
terminal interface then requests a terminal from the payment selects that terminal until the security card finally issues a 
server's terminal pool. The payment server has a pool of 45 "confirmation" message and is released by a terminal inter- 
terminals connected to the terminal concentrator that is face. Thus, in some circumstances it is desirable to release 
established at start-up. At start-up, the payment server the security card earlier. By releasing a security card earlier, 
receives a list of all valid terminal identifiers. The payment the card is tied up for a shorter lime per transaction and may 
server uses these identifiers, and its knowledge of transac- move on to the next transaction sooner. Also, the less time 
lions in progress to determine an appropriate terminal to 5Q that a terminal is dedicated to a particular transaction, and 
process the transaction. Once a terminal is determined, the the fewer messages exchanged between the two, the less 
terminal interface builds a terminal specific message based likely chance there is of a communication error that might 
upon the draw request and the type of terminal. interrupt and halt the transaction. 

In step 686 the terminal specific draw request 312 is sent Embodiment 200« includes a client terminal 204, a pay- 
to the chosen terminal via the concentrator over a local area 55 ment server 206, a merchant server 208, a stored-value card 
network. The concentrator acts as a router between a trans- 5, and a terminal 214 having a security card 218. Commu- 
action thread in the payment server and its corresponding nicatioo between the various entities may take place in a 
terminal. The concentrator looks at a header on the draw similar fashion as in FIG. 5 as indicated by communication 
request to determine to which terminal the transaction links 234,235, and 236. However, instead of two round trips 



should be routed. In one embodiment of the invention, 60 of information between the terminal and payment s 

concentrator 212 is removed and payment server 206 com- there is only one round trip in this embodiment, 

municates directly with terminal 214 (for example). FIG. 12 is a flowchart that describes a technique for 

In step 688 the terminal parses the draw request message implementing this embodiment with reference to FIG. 6. 

into its various components and processes each component Step 702 indicates that communication between the various 

in turn to emulate a stored-value card interacting with the 65 entities takes place in a similar fashion as in FIG. 5 up until 

security card in a physical terminal. Prepackaging of a the terminal reaches the "draw amount" state. At this point, 

variety of information into the draw request message results draw request 312 has been received and processed by the 
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security card. Next, in step 704 the security card generates not only the security card signature and the debit command, 

not only the security card signature and the debit command, but also an expected stored-value card signature, 

but also an expected stored-value card signature. This In step 726 the security card signature, the debit command 

expected stored-value card signature is a value expected by and this expected stored-value card signature are sent to the 

the security card from the stored-value card to validate the s payment code module in the payment server as indicated in 

stored-value card's success message. This validation will 314a. Also, the terminal updates its data store in a similar 

ensure that the stored-valued card has in fact debited itself. fashion as in step 630. Next, in step 728 the payment server 

In step 706 the security card signature, the debit command code module sends the debit command, merchant signature 

and the expected stored-value card signature are sent to the and expected stored-valued card signature to the client 

payment code module in the payment server as indicated at 10 terminal. 

314a. Also, the terminal updates its data store in a similar Next, step 730 indicates that the transaction occurs as 

fashion as in step 630. Next, step 708 indicates that the before with reference to steps 618 and 620. The steps 

transaction occurs as before with reference to step 616-622. indicate that the stored-value card receives the debit com- 

The steps indicate that the stored-value card receives the mand and debits itself. In step 732, the client code module 

debit command, debits itself, and returns the success mes- 15 itself compares the actual card signature from the stored- 

sage (also termed a "debit response" message) and its card value card with the expected signature from the security 

signature to the payment server. card. This comparison of the two signatures by the client 

Next, in step 710 the payment server code module pro- module of the client terminal foregoes the need for another 

cesses this response from the stored-value card by compar- round trip between the payment server and the client termi- 

ing 346 the received card signature with the expected 20 nal. Also, because the security card has already delivered the 

stored-value card signature received earlier from the security expected card signature to the payment server, the security 

card. This comparison of the two signatures by the payment card may be released as soon as message 314a is received, 

module of the payment server foregoes the need for another Assuming that the comparison is successful, the client 

round trip between the payment server and the security card. terminal is then able to generate its own confirmation 

Because the security card has already delivered the expected message in step 734 instead of waiting for a confirmation 

card signature to the payment server, the security card may message from the payment server. Next, step 736 indicates 

be released as soon as message 314a is received. that the processing continues in a similar fashion as in steps 

Assuming that the comparison is successful, the payment 636-640. The confirmation message is passed on to the 

module is then able to generate its own confirmation mes- 3Q merchant server and the merchant server may then deliver 

sage instead of waiting for a "confirmation" message from the purchased merchandise to the user, 
the security card. Next, step 712 indicates that the process- 
ing continues in a similar fashion as in steps 632-640. The 
confirmation message is passed on to the merchant server by 

way of the client terminal and the merchant server may then 3J FIG. 8 illustrates another embodiment 200c of the inven- 

deliver the purchased merchandise to the user. tion in which the merchant server performs the comparison 

of the stored-value card signature with the expected signa- 
ture. This embodiment has all of the advantages of the 
previous embodiment in which the security card is released 

In another embodiment 2006 of the present invention as 40 earlier, and there are also fewer messages passed between 

illustrated in FIG. 7, not only is the security card allowed to the entities. In this embodiment, if the client terminal is not 

release earlier, but the number of messages exchanged to be trusted to compare the stored-value card signatures, 

between the client terminal and the payment server are then an encrypted signature is passed to the merchant server 

reduced. Instead of comparing stored-value card signatures v <a the client terminal. The client terminal also passes the 

in the payment server, the expected stored-value card sig- 45 raw, unencrypted signature from the stored-value card to the 

nature from the security card is transmitted to the client merchant server. A routine 366 in the merchant server then 

terminal where a trusted agent 356 performs the comparison compares the two signatures. 

of the expected stored-value card signature with the actual Embodiment 200c includes a client terminal 204, a pay- 
signature received from stored-value card 5. Thus, message ment server 206, a merchant server 208, a stored-value card 
exchange between the client terminal and the payment 50 5, and a terminal 214 having a security card 218. Commu- 
server is reduced to one round trip. This is advantageous in nication between the various entities may take place in a 
that the time for a transaction is reduced, the security card similar fashion as in FIG. 5 as indicated by messages 
is released earlier and fewer message exchanges means more 302-306 and communication link 235. 
reliability over the Internet. FIG. 14 is a flowchart that describes a technique for 

Embodiment 200fc includes a client terminal 204, a pay- ss implementing this embodiment with reference to FIG. 8. 

ment server 206, a merchant server 208, a stored-value card Step 742 indicates that communication between the various 

5, and a terminal 214 having a security card 218. Commu- entities takes place in a similar fashion as in FIG. 5 up until 

nication between the various entities may take place in a the terminal reaches the "draw amount" state. At this point, 

similar fashion as in FIG. 5 as indicated by communication draw request 312 has been received and processed by the 

links 234 and 235. 60 security card. Next, in step 744 the security card generates 

FIG. 13 is a flowchart that describes a technique for not only the security card signature and the debit command, 

implementing this embodiment with reference to FIG. 7. but also an expected stored-value card signature. 

Step 722 indicates that communication between the various In step 746 the security card signature, the debit command 

entities takes place in a similar fashion as in FIG. 5 up until and this expected stored-value card signature are sent to the 

the terminal reaches the "draw amount" state. At this point, 65 payment code module in the payment server as indicated in 

draw request 312 has been received and processed by the 314a. Also, the terminal updates its data store in a similar 

security card. Next, in step 724 the security card generates fashion as in step 630. Next, in step 748 the payment server 
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code module sends the debit command, merchant signature 
and an encrypted expected stored-valued card signature to 
the client terminal. The expected stored-valued card signa- 
ture is encrypted to prevent tampering by the client terminal 
or other outside entity. 

Next, step 750 indicates that the transaction occurs as 
before with reference to steps 618 and 620. The steps 
indicate that the stored-value card receives the debit com- 
mand and debits itself. In step 752, the client code module 
sends the success message, the raw stored-value card sig- 
nature and the encrypted signature on to the merchant server. 
In step 754 the merchant server processes the success 
message, decrypts the encrypted signature, and compares the 
two signatures. This comparison of the two signatures by the 
merchant server foregoes the need for another round trip 
between the payment server and the client terminal. Also, 
because the security card has already delivered the expected 
card signature to the payment server, the security card may 
be released as soon as message 314a is received. 

Assuming that the comparison is successful, the merchant 
server is then able to generate its own confirmation message 
in step 756 instead of waiting for a confirmation message 
from the client terminal. Next, step 758 indicates that the 
processing continues in a similar fashion as in steps 638 and 
640. The merchant server may then deliver the purchased 
merchandise to the user. In all of the above alternative 
embodiments, when the transaction is not completed 
successfully, the payment server reverses the transaction 
within the terminal. 

ENCRYPTION LAYER EMBODIMENT 

FIG. 9 illustrates an embodiment 200d of the present 
invention in which an encryption layer has been added. 
Although the present invention may be practiced without 
this added encryption layer, in a preferred embodiment of 
the invention, this encryption layer is used. FIG. 9 includes 
client terminal 204, payment server 206 and merchant server 
208. Other elements of the architecture have been omitted in 
this figure for simplicity. This extra encryption layer is used 
not only to protect the contents of messages being transmit- 
ted over the Internet, but also to prevent a client terminal, 
stored-value card or other entity from receiving or producing 
a message that would trick another entity into thinking that 
a valid transaction had occurred. This encryption also pre- 
vents messages from being accidentally or deliberately 
altered or misdirected. 

It should be appreciated that encryption may be present in 
any embodiment on all parts of any message sent for 
security. Preferably, any signature sent over a network is 
encrypted. 

FIGS. 15A and 15B are a flowchart describing this 
embodiment of the invention with reference to FIG. 9. In 
step 802, the payment server and the merchant server share 
a unique encryption key. Through a prior business 
arrangement, both of the servers have arranged to share this 
unique key to add security to the transaction. The shared key 
may be of any suitable encryption standard and of any 
length. The key may be a Data Encryption Standard (DES) 
key having a length of 128 bits including parity. Although 
this shared key could be used directly, in a preferred 
embodiment of the invention, there is a derived unique key 
for each transaction between the merchant server and the 
payment server. Alternatively, another encryption standard 
such as RSA may also be used. Preferably, loading of value 
is performed under DES, while a purchase may be per- 
formed under either DES or public key technology. 
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In step 804 the client terminal and the merchant server 
engage in a protected Secure Sockets Layer (SSL) session 
404 in which a connection is made, a user browses and 
makes a purchase selection. The SSL session protects the 

5 information transmitted over the Internet such as card 
information, commands, and encryption keys from being 
discovered by an unauthorized party. Other techniques for 
protecting a session may also be used. 

In step 806 the merchant server derives a key from the 

10 DES key using information unique to the transaction such as 
the merchant identifier, the transaction identifier, or other 
information unique to this transaction, such as a random 
number. Because the payment server shares the DES key 
with the merchant server and also has access to this unique 

15 information about the transaction, the payment server will 
also be able to derive this same key from the shared DES 
key. In this step the merchant server also creates a transac- 
tion session key (TSK) for use by the client terminal and 
payment server in encrypting information. 

20 In step 808 the merchant server downloads an HTML 
page of information 406 that includes the TSK and the TSK 
that is encrypted using the derived key (ETSK). The TSK 
encrypted with the derived key will be used by the payment 
server to return an encrypted (and unreadable by the client) 

25 confirmation message to the merchant server. Only the 
merchant server will be able to decrypt this confirmation 
message and will thus be guaranteed that a successful 
transaction has occurred and that merchandise may be 
released to the client. 

In step 810, the client prepares the draw request in 
conjunction with the stored-value card and sends the draw 

request 408 encrypted with the TSK to the payment server 
along with the ETSK. In step 812 the payment server uses 

35 the shared DES key and the prearranged information unique 
to the transaction to derive the same key that the merchant 
server has used. Thus, the derived key can be used to decrypt 
the ETSK in order to produce the TSK. Once the payment 
server had produced the TSK, it may decrypt the draw 

40 request and process the draw request in any suitable fashion 
with the security card. Once the payment server has received 
the debit command from the security card, it encrypts the 
debit command with the TSK. The debit command may also 
be termed the "debit IEP command." 

45 In step 814 the payment server sends the encrypted debit 
command 410 to the client terminal. In step 816 the client 
decrypts the debit command with the TSK it had received 
earlier from the merchant server and processes the debit 
command in a suitable fashion with a stored-value card. 

50 Once the client terminal has received the debit response 
message from the stored-value card, it encrypts this message 
with the TSK and sends the debit response message 412 to 
the payment server. In step 820, the payment server decrypts 
the debit response message with the TSK and processes the 

55 debit response message in a suitable fashion with the secu- 
rity card. 

Once the payment server has received a "debit result" 
message from the security card, the payment server encrypts 
the "debit result" message with the TSK to form a "debit 

60 result C" message for the client. The "debit result C" 
message will be used by the client terminal to inform the 
user of a successful transaction. The payment server also 
generates its own confirmation message and encrypts the 
confirmation message with the derived key to form a "debit 

65 result M" message. The payment server then sends 414 the 
"debit result C" message and the "debit result M" message 
to the client terminal. 
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In step 822 the client terminal decrypts and processes the 
"debit result C" message and passes the "debit result M" 
message 416 on to the merchant server. Because the "debit 
result M" message is encrypted with the derived key, the 
client terminal or other entity is not able to tamper with it. s 
In step 824 the merchant server is able to decrypt the "debit 
result M" message because it had originally produced the 
derived key from the DES key. Once the merchant server has 
determined that a valid "debit result M" message has been 
received, it confirms that a valid transaction has taken place 10 
and may release merchandise to the user. 

This security embodiment of FIG. 9 may be used with any 
of the previously described embodiments of the invention. 
By way of example, this security embodiment may be used 
with the embodiments of FIGS. 7 and 8 in which there is 15 
only one round trip between the client terminal and the 
payment server. In particular, the expected stored-value card 
signature received from the security card may be encrypted 
with the derived key so that it unreadable by the client, yet 
the merchant server will be able to compare the received 20 
stored-value card signature with the expected card signature 
to validate the transaction. 

A wide variety of terminology may be used to describe the 
keys described above. For example, the keys referred to 
above as shared DES key, transaction session key (TSK) and 25 
derived key, may also be referred to as shared key, session 
C key and session M key. 

AUTHENTICATION EMBODIMENT 

30 

FIG. 16 illustrates an architecture and system 200' for 
authentication over an internet (such as the Internet) using a 
pseudo stored-value application. This application could 
reside on a stored-value card along with standard accounts, 
stored value, or other card applications. The card defines 35 
access to the pseudo stored-value service and ensures that 
the card is present and passes security checks. 

In one embodiment of the present invention, a consumer 
may wish to access any of a variety of Web servers in order 
to redeem frequent flyer miles, award points, etc., that he or 40 
she has accumulated. In this embodiment, a consumer has 
accumulated "points" through any of a variety of programs 
with airlines, restaurants, rental car companies, hotels, 
banks, credit or debit card issuers, telephone or other com- 
munication company, etc. The consumer wishes to redeem 45 
these points to receive free airline tickets, meals, car rental, 
overnight stays, prizes, awards, discounts, or other "ben- 
efits". By accessing a Web server associated with the par- 
ticular program, the consumer is able to use his or her card 
in any of the embodiments described herein to authenticate 50 
the card and to receive these benefits from the program. 
Most often, a card has a card number that is associated with 
the consumer's name in a database on the Web server. This 
card number is transmitted to the Web server as part of the 
card signature, or in a similar fashion. Thus, an authenticated 55 
card used in this embodiment to redeem services may be 
matched to the appropriate consumer. 

For example, a consumer with 30,000 frequent flyer miles 
on one airline may use this embodiment of the present 
invention to access a Web server associated with the airline. 60 
The consumer is requesting a free round-trip ticket in 
exchange for 20,000 miles. The present invention then 
operates to authenticate the consumer's stored-value loyalty 
application on the card, and delivers a confirmation of 
authentication message to the Web server for the airline. The 65 
Web server then deducts 20,000 miles from the consumer's 
account (leaving 10,000 miles) and delivers the free ticket to 



the consumer. In one specific embodiment, the Web server 
associated with the airline (or the airline itself) keeps track 
of the consumer's account and deducts the mileage. In this 
instance, an authentication application is used to validate the 
presence of the card or to obtain access to the Web server 



In another specific embodiment, the consumer's card 
contains a loyally application that stores the consumer's 
accumulated frequent flyer mileage; the mileage from the 
card is then debited and confirmed to the Web server in a 
similar fashion as described in various of the embodiments 
by which a cash value is stored on and debited from a card. 

System 200' may be implemented in a similar fashion as 
system 200 of FIG. 4. The elements shown in system 200' 
having counterparts in system 200 are described above and 
have similar functionality. System 200' includes a web 
server 208' that may be any suitable computer server capable 
of presenting award information (hereinafter "benefits") to a 
consumer over an open network such as the Internet. Web 
server 208' may be the same as merchant server 208 of FIG. 
4 or a separate computer. Preferably, web server 208' is 
implemented in a similar fashion as described above for 
merchant server 208. Web server 208' includes server mod- 
ule 232' that is preferably implemented in a similar fashion 
as merchant module 232. Additionally, server module 232' 
includes functionality to store and present benefits that are 
available for particular consumers. For example, benefits 
available such as airline tickets, prizes, etc., may be pre- 

Points (such as frequent flyer miles, for example) that a 
consumer accumulates to achieve benefits may be linked to 
a particular consumer by an account number, password, or 
other identifier. The amount of points accumulated for each 
consumer may be stored on web server 208' using server 
module 232', or may be located in another database of the 
organization providing the benefits. In an alternative 
embodiment, these points for each program that a consumer 
is enrolled in are stored in a loyalty application on the 
consumer's card. For example, a consumer may have a 
stored-value card that in addition to storing monetary value, 
also stores a quantity of frequent flyer miles accumulated for 
a particular airline (or a number of airlines), points accu- 
mulated for using a particular credit card, points for hotel 
stays at particular hotels, etc. For points stored on the 
consumer's loyalty application card, these points may be 
verified and debited in much the same way that monetary 
value on the consumer's card is debited as described herein. 

One embodiment by which a consumer has his or her 
pseudo stored-value application on a card authenticated to 
redeem points for benefits will now be explained. In one 
specific embodiment, a technique similar to that described in 
the flowchart of FIGS. 11A-11D for debiting monetary 
value may be used. Initially, a user (consumer) operating 
client terminal 204 accesses web server 208' over link 234', 
views benefits presented for a particular program (such as an 
airline's frequent flyer program), selects benefits from that 
program, and requests the transaction to be performed using 
his or her pseudo stored-value application to validate that the 
card has access to the services. Web server 208' receives and 
processes this request. The above steps may be performed in 
a similar fashion as steps 602 and 604. 

Next, similar to step 606, web server 208' sends a page of 
information to client terminal 204. When claiming benefits, 
the total cost field is zero and the currency field is a specially 
assigned value. Keeping total cost field equal to zero causes 
the system to perform authentication but not to create a 
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payment record. Alternatively, for those user's whose card 
holds the amount of their points, additional fields may be 
sent from server 208' to terminal 204 indicating which 
account to debit and by how many points. The total cost and 
currency fields may be readily adapted for this purpose. 5 

Next, in a similar fashion to steps 608-612, a draw request 
message is built, and the draw request is sent to authenti- 
cation server 206' over link 236*. Similar to step 614, the 
authentication server now processes the draw request in 
conjunction with security card 218 (for example) and sends 10 
back a "debit" command and a security card signature to 
authentication server 206'. As total cost is zero, the "draw 
amount" state reached by security card 218 is also zero. In 
the alternative embodiment in which stored-value card 5 
stores points for a particular program, total cost may be a 15 
value and a "draw amount" state may be reached indicating 
a number of points to be deducted from card 5. 

Next, similar to steps 616-618, authentication server 206' 
sends the debit command and security card signature to 
client terminal 204 and this information is processed by card 20 
5. Even though a monetary value is not being debited, card 
5 performs processing such as incrementing a counter indi- 
cating number of transactions and generating a stored-value 
card signature. In the alternative embodiment in which 
points are stored on card 5, the points needed to redeem the 25 
benefit chosen by the user from web server 208' may be 
debited from the appropriate account in this step. 

Steps 620 through 638 are performed in a similar manner 
as in FIGS. 11B and 11 C, except that in this case a monetary 3Q 
transaction is not being verified, but rather card 5 is being 
authenticated to allow the user to complete his access to 
services or benefits. In step 626 in particular, the signature 
of card 5 is verified by security card 218. In this 
embodiment, security card 218 would send an "authentica- J5 
tion OK" message rather than the "confirmation" message of 
step 628. Web server 208' then debits the appropriate num- 
ber of points from the user's account or allows access to a 
privileged service for the benefit requested. In the alternative 
embodiment in which points are stored on card 5, the 4Q 
"authentication OK" message serves not only as an authen- 
tication of card 5, but also confirmation that the correct 
number of points have been debited from card 5 for the 
appropriate program. Next, similar to step 640, web server 
208' releases the benefit requested by the user (such as 4J 
airline tickets, prizes, discounts, etc.) and the benefit is 
arranged to be delivered to the user. 

It should be appreciated that this technique of redeeming 
points for benefits may also be practiced using any of the 
alternative embodiments of FIGS. 6, 7 or 8, thereby obtain- 50 
ing the advantages associated with those embodiments. 
Furthermore, this technique may take advantage of the 
encryption layer embodiment of FIG. 9. Additionally, as 
described below, the present invention may also be used to 
load more points onto card 5 in much the same way that 55 
monetary value is added. 

LOADING A STORED-VALUE CARD 
FIG. 17 illustrates a system 850 for loading value onto a 
stored-value card according to one embodiment of the 60 
present invention. System 850 includes a client terminal 
204, bank server 860 and load server 862. Client terminal 
204 communicates with card 5 via card reader 210, and with 
bank server 860 and load server 862 over any suitable open 
network such as Internet 202. Suitable embodiments for the 65 
client terminal, the card reader and the stored-value card are 
described above in the description of a payment technique. 



Preferably, each of client terminal 204, bank server 860 and 
load server 862 implement a code module (similar in opera- 
tion to the code modules described above) in the Java 
programming language that provides the functionality 
described below. For simplicity of explanation, reference 
will be made below to "client terminal", "bank server" and 
"load server" even though the resident code is performing 
the functions. Card issuer 108 has been described previously 
in FIG. 3. Card issuer 108 may be a separate financial 
institution from the bank that includes bank server 860, or 
card issuer 108 may be the same bank that includes bank 
server 860. 

Bank server 860 is any suitable computer within a bank or 
other financial institution. By way of example, bank server 
860 is any suitable personal computer, a workstation or a 
mainframe computer. In one embodiment, bank server 860 
runs a "servlet" program (a Java applet running on server) 
for communication with client 204. 

Load server 862 is also any suitable computer and may be 
located at a third party location (such as at a processor) or 
may be located within the same bank as bank server 860. 
Load server 862 also runs a servlet program for communi- 
cation with client terminal 204 and host security module 
864. In an alternative embodiment, load server 862 and bank 
server 860 are the same computer which runs two different 
applications representing the functionality of each server. 

Host security module (HSM) 864 is a device known in the 
art that may be embodied in a hardware "black box" or on 
any suitable computer. The host security module can be 
implemented in a hardware module outside of load server 
862, can be implemented within load server 862, can be 
implemented in software, or can be implemented as a 
security card described above. Host security module 864 
contains the encryption keys in hardware used for generating 
signatures (for example SI, S2 and S3) that provide security 
for the transaction. These signatures are used by stored- 
value card 5 and host security module 864 to insure that the 
card is not expired or counterfeit (i.e., is a valid card), to 
insure that module 864 is authentic, to insure that system 
850 is authentic and, in general, to provide for a valid 
transaction and to prevent fraud. Card 5 also includes 
encryption keys for the generation of a stored-value card 
signature. In an alternative embodiment, module 864 could 
be replaced by a standard terminal that includes a security 
card such as is shown in the previous embodiments. In this 
situation, the encryption keys would be stored in the security 

Briefly, system 850 operates as follows. A consumer 
accesses bank server 860 via client terminal 204. Assuming 
that card 5 is not overloaded and that the user's account with 
the bank has sufficient funds, the user is able to download 
value via bank server 860 on to his stored-value card 5. 
Client terminal 204 communicates with load server 862 to 
receive authorization for the load and for higher security. 
Card 5 may then be used to make purchases over the Internet 
as described earlier in the application or may be used for 
purchases elsewhere. Once the bank has downloaded value 
to caud 5, a corresponding amount of funds is transferred 
from the bank to card issuer 108. 

Card issuer 108 places these funds in a holding pool. Once 
stored-value card 5 is used to make a purchase from a 
merchant, the transaction is captured and setded through a 
settlement service, such as VisaNet. The issuer bank decre- 
ments the funds pool for the amount of the purchase, which 
is paid to the merchant bank. The merchant bank pays the 
merchant for the transaction. Settlement may occur in any 
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suitable fashion such as is known in the art and, in particular, In step 876 the client terminal interacts with stored-value 

may be implemented as previously described in FIG. 3. card 5 to obtain card information in order to build a load 

request message for later transmission to load server 862. 
LOADING DETAILED TRANSACTION FLOW Once responses from the card are received, the client ter- 
. 5 minal combines these responses into a byte stream suitable 
One embodiment of a technique by which a stored-value for transmission over a network to a load server, 
card is loaded over the Internet will now be described using ^ dient lt[min!ll emu i ates a variety of host security 
the flowchart of FIGS. 18A through 18D with reference to module 864 commands to receive responses from these 
FIG. 17. Various of the steps below may occur in a different commands from the stored-value card. The stored-value 
order; the following description is for illustration purposes. car d and the security module are physically separated from 
Interaction between client terminal 204 and bank server 860, one another; communication takes place over the Internet. In 
and between client terminal 204 and load server 862, is the interest of speed and reliability, it is advantageous to 
preferably implemented in a similar fashion as between have only the traditional authentication, response, and con- 
client terminal 204 and merchant server 208, and between firmation messages exchanged. 

client terminal 204 and payment server 206 as described To operate securely and reliably in this environment, in 

above, respectively. Certain implementation details men- 1 one embodiment of the present invention the client terminal 

tioned above with respect to payment are equally applicable emulates a security module and gathers all the responses for 

to loading a stored-value card. Furthermore, the exemplary transmission into one load request message. The load 

flow shown in the figures illustrates a successful transaction request message may include a variety of information and 

(although a negative result is also explained below in the preferably includes a first card signature (termed SI), a card 

text). For this reason, a "confirmation" message is referred 20 number, an expiry date, and a load amount. Other informa- 

to, which can more broadly be referred to as a "result" * oa such security algorithm, transaction counter, 

message (to reflect both the possibilities of success and current card balance, and bank server time stamp are also 

failure of a load). Also, a "load success" message is referred preferably provided. . . . 

to, which can also be referred to as a "confirmation" As all of tfus information is prepackaged into a single load 

message to reflect its status as either confirming a positive » = Sl^S^S 

load result or a negative load result. the Internet is minimized. 

Initially, a suitable web browser of client terminal 204 is Next> in slep 877 the client terminal accesses the load 

used by the user to access a bank server Internet site. In step server the , p address reC eived from the bank server. In 

871 the user selects an option to load value onto card 5. In 3Q step g78 lhe cl ; en t terminal sends the load request message 

step 872 the bank server sends a request for card information t o the load server. In step 879 the load server processes the 

(including current card balance and maximum card balance); load request in conjunction with an associated host security 

client terminal 204 reads the current card balance, currency, module 864 as will Be explained in greater detail below with 

and other card information via card reader 210 and returns reference to FIG. 18D. After step 879, the load server has 

the balance to bank server 860. In step 873 the bank server 3J received an issuer security module signature (termed S2) as 

determines the maximum load value and verifies, that enough pa rt of a load command from the security module 864. The 

funds are in the user's account to accommodate a load security module signature is a value that uniquely identifies 

request. and validates the security module to prove to stored-value 

In step 874 the bank server builds an HTML page that card 5 that the incoming load command is a valid command 
includes the following client applet parameters: the load 40 from a real security module. Thus, the user of the stored- 
value; the type of currency being used; the port and IP value card, and other interested parties are guaranteed that a 
address of the load server; a unique transaction identifier valid load of the card has occurred. In a preferred embodi- 
used by both the load server and the bank server to track a ment of the invention, the security module signature is an 
transaction; a unique bank identifier assigned to the bank encrypted value ensuring that no other entity can forge an 
and known to the load server; and a session key. Other 45 identity of a security module. 

information may also be included such as the currency's In step 880 the load server sends the load command 

exponent, a status URL address of the bank server used for including with the security module signature to the client 

communication from the client terminal, and other security terminal for the stored-value card to load itself. In step 881, 

information to ensure the identity of the bank server and the upon receiving the load command from the load server, the 

integrity of the message. Other process related information 50 client terminal passes the load command to stored-value 

such as software release level, encryption methodology and card 5 which verifies the signature, loads itself by the load 

keys may also be conveyed. Once this page has been built, value, and also generates a load success message, a second 

the page is sent to the requesting client browser and triggers stored-value card signature (termed S3), and a result code 

the activation of the client code module (in this example a indicating success or failure of the load. In a preferred 

Java applet) in the client terminal. 55 embodiment of the invention, this signature is in encrypted 

To determine the load value, the bank server requests that form to prevent tampering, 

the user enter the amount to load to the card. Assuming that In step 882, card 5 sends load success message containing 

the user's account is adequate, the bank server requests the the card signature (S3) and result code back to client 

user's account be debited in step 875 by the load value. terminal 204. Next, in step 883 client terminal 204 packages 

Advantageously, the debit request from the bank server can 60 the load success message along with the card signature and 

use the existing ATM and accounting systems of the bank to sends them back to load server 862. In step 884 the load 

debit the user's account. From the bank's point of view, server receives the incoming message. The load server then 

value is being transferred from the user's account much in processes the message into its components and directs the 

the same way that value would be transferred to a user in the components to the security module. Next, in step 885 the 

form of cash at an ATM. In this situation, though, the value 65 security module may process this response from the client's 

is not being dispensed as cash at an ATM, but is being sent terminal and verify the received stored-value card signature 

over the Internet to a stored-value card. (S3). 
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As the security module contains the keys and algorithms 
necessary to compute stored-value card signatures, the secu- 
rity module is able to validate that a received stored-value 
card signature is in fact a valid one by comparing the 
received stored-value card signature with a generated : 
expected value. A successful comparison indicates that a 
load success message received from the stored-value card is 
in fact a valid success message and that the stored-value card 
has been loaded. Assuming that the transaction is so far 
valid, in step 886 the security module sends a "confirmation" 1 
message back to the load server. 

It is possible that the stored-value card has not been 
loaded by the proper amount, that the card is invalid, a user 
is fraudulent or another discrepancy. For example, it is 
possible that a user has tampered with the card to make it 1 
appear that a load has not occurred, when in fact a load has 
occurred. In this situation, processing in step 882 and on is 
slightly different. For example, instead of generating a "load 
success" message, the card my generate a "negative result" 
code, potentially indicating that the card has not been 2 
loaded. Processing of this situation would then occur as 
follows. 

In step 882, card 5 sends a load message containing the 
result code and stored-value card signature S3 back to client 
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loaded card. If there is a match, it means the negative result 
was correct and that the transaction counter had been 
increased by accident. The user account is not debited, and 
not settlement occurs. 

Returning now to further processing, in step 887 the load 
server logs the response received from the security module 
and updates its database with the transaction identifier, the 
bank identifier, the load value, etc. In general, any of the 
plethora of information passing through the load server may 
be added to its database. Next, in step 890 the load server 
creates a confirmation message including the transaction 
identifier and sends this message to the client terminal in 
encrypted form. By sending this confirmation message in 
encrypted form, the confirmation message may be for- 
warded to the bank server by way of the client terminal 
without fear of tampering. As the confirmation message is 
encrypted, it would be difficult for the client terminal or 
another entity to forge a confirmation message and trick the 
bank server into thinking that a valid load had taken place. 

In step 891 the client terminal forwards the confirmation 
message on to the bank server at the URL address previously 
received from the bank server. The client terminal may also 
post a message to the user informing that the load has been 
completed. The client terminal may also log confirmation of 



terminal 204. Client terminal 204 recognizes a negative 15 the load. In step 892 the bank server rt 
result code, and invokes negative result handling. Client 
terminal 204 interacts with card 5 and generates a new load 
request for a zero value load using elements from the 
original request, along with a new card signature SI. 

The negative result code, along with the signatures S3 and 
new SI, and the zero value load request are passed to the 
load server for analysis. The load server determines if the 
transaction counter in the zero value load equals the trans- 
action counter in the previous request, along with verifying 
other pertinent information such as date and time, card 
number, and currency code and exponent. If the transaction 
counters are the same, then it is possible that a valid negative 
result has been received, but it should be verified because the 
client is not trusted. If the counters are equal, the load server 
will hold the original S3 and will generate a new load 
request to the security module using data element values that 
would have been expected if the original transaction had 
failed. The new load request along with the new SI is sent 
to the security module. The security module then compares 
the original SI (from the original load request) to the 



s the confir- 
mation message. The bank server calls a routine to decrypt 
the confirmation message. If the decrypted confirmation 
message is acceptable, the bank server determines a suc- 
cessful load has occurred. The confirmation message pro- 
30 vides assurance to the bank that the user's card was in fact 
loaded with a particular value and prevents fraud. For 
example, a fraudulent user who tries to claim that his bank 
account was decremented and his card not loaded (and 
should thus receive more money from the bank) would be 
35 thwarted because the confirmation message proves that the 
user's card was in fact loaded. Alternatively, the "confirma- 
tion" message may indicate that a load did not occur, in 
which case the account would not be debited, and no 
settlement would occur. 
40 At this point a successful load of the user's card has 
occurred (assuming all is well). For example, if the user had 
requested $100, that amount has been decremented from the 
user's account at the bank, and $100 has been loaded onto 
the user's stored-value card. Preferably, at this point the 
45 amount loaded (in this example $100) is transferred from the 
SI. If SI is valid, then the original negative result is true and bank to the stored-value card issuer preferably through an 
the security module generates a signature to confirm to the existing network. The $100 is transferred so that the card 
load server that there was no load. The original negative issuer may manage the float on these unspent funds until the 
result from the card is then released to the security module user spends the $100. Once the $100 (or a smaller portion) 
to complete the original transaction. Processing would 50 has been spent with a merchant, the card issuer is then able 
continue, but a user account would not be debited, and no to settle the transaction with the merchant using any suitable 
settlement need occur because the card was, in fact, not clearing and administration system. In alternative 
loaded. If SI is not valid, the negative response is not true embodiment, the bank may retain the $100 and settle 

directly with the merchant. In another embodiment, the bank 
and the card issuer are the same financial institution, and the 
$100 may be shifted between parts of the organization or 

Returning now to a more detailed discussion of step 879, 
FIG. 11D describes a technique for processing a load request 
message in conjunction with a security module. Once the 
load request message is received by the load server, the load 
server parses it into the appropriate elements and passes a 
request to the security module as will be explained below. 
Alternatively, the load server can build a network message 
and switch the request to a remote authentication server. Or, 
a smart terminal could parse the message and pass responses 
to the security module. 



and then the result code in the original request is changed to 
reflect a successful load and passed to the security module. 5 
Processing then continues reflecting that a load has 
occurred. 

On the other hand, if the transaction counters are not the 
same, then it is still possible that a valid negative result has 
been received, but it should be verified because the client is t 
not trusted. First, the load server decreases the transaction 
counter in the new load request to match that of the original. 
The request along with the new SI is passed to the security 
module. The security module calculates its own new SI 
based upon the modified new load request. If there is no 6 
match, it means that the negative result was in error and that 
the card had been loaded. Processing continues to reflect a 
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In step 895 the load server edits the load request for 
syntactic correctness and logs the request as received. In step 
896 the load server constructs a load request message. In 
step 897 the load server passes the load request to the 
security module to emulate a stored-value card interacting 
with the security module. The load server behaves as if a 
stored-value card were actually interacting in an ATM (for 
example) through a network to a host with a security 
module. In this fashion, the load request originating from the 
client terminal has been sent in prepackaged form over the 
Internet emulating a traditional interaction between the 
stored-value card in an ATM. 

In step 898, the security module verifies the received 
stored-value card signature (SI) to prevent fraud. The secu- 
rity module generates its security module signature (termed 
S2) and the load command. The signature S2 will confirm to 
the client terminal and the stored-value card that the host 
security module is authentic and belongs to the issuer of the 
stored-value card. Additionally, S2 protects against a user 
trying to perform a fake load, keys out of synchronization, 
a counterfeit card, an expired card, etc. The security module 
then sends the signature and load command to the load 
server as indicated in step 899. At this point, step 879 ends 
and control returns to step 880. 

COMPUTER SYSTEM EMBODIMENT 

FIG. 19 illustrates a computer system 900 suitable for 
implementing an embodiment of the present invention. 
Computer system 900 includes any number of processors 
902 (also referred to as central processing units, or CPUs) 
that are coupled to storage devices including primary storage 
906 (such as random access memory, or RAM) and primary 
storage 904 (such as a read only memory, or ROM). As is 
well known in the art, primary storage 904 acts to transfer 
data and instructions uni-directionally to the CPU and 
primary storage 906 is used typically to transfer data and 
instructions in a bi-directional manner. Both of these pri- 
mary storage devices may include any suitable of the 
computer-readable media described below. A mass storage 
device 908 is also coupled bi-directionally to CPU 902 and 
provides additional data storage capacity and may also 
include any of the computer-readable media described 
below. Mass storage device 908 may be used to store 
programs, data and the like and is typically a secondary 
storage medium (such as a hard disk) that is slower than 
primary storage. It will be appreciated that the information 
retained within mass storage device 908, may, in appropriate 
cases, be incorporated in standard fashion as part of primary 
storage 906 as virtual memory. A specific mass storage 
device such as a CD-ROM 914 passes data uni-directionally 
to the CPU. 

CPU 902 is also coupled to an interface 910 that includes 
one or more input/output devices such as such as video 
monitors, track balls, mice, keyboards, microphones, touch- 
sensitive displays, transducer card readers, magnetic or 
paper tape readers, tablets, styluses, voice or handwriting 
recognizers, biometrics readers, or other computers. CPU 
902 optionally may be coupled to another computer or 
telecommunications network using a network connection as 
shown generally at 912. With such a network connection, it 
is contemplated that the CPU might receive information 
from the network, or might output information to the net- 
work in the course of performing the above-described 
method steps. Furthermore, method embodiments of the 
present invention may execute solely upon CPU 902 or may 
execute over a network connection such as the Internet in 




a remote CPU that shares a portion of the 
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In addition, embodiments of the present invention further 
relate to computer storage products with a computer read- 
able medium that have program code thereon for performing 
various computer-implemented operations. The media and 

5 program code may be those specially designed and con- 
structed for the purposes of the present invention, or they 
may be of the kind well known and available to those having 
skill in the computer software arts. Examples of computer- 
readable media include, but are not limited to: magnetic 

10 media such as hard disks, floppy disks, and magnetic tape; 
optical media such as CD-ROM disks; magneto-optical 
media such as floptical disks; and hardware devices that are 
specially configured to store and execute program code, 
such as application-specific integrated circuits (ASICs), 

15 programmable logic devices (PLDs) and ROM and RAM 
devices. Examples of program code include machine code, 
such as produced by a compiler, and files containing higher 
level code that are executed by a computer using an inter- 

20 Although the foregoing invention has been described in 
some detail for purposes of clarity of understanding, it will 
be apparent that certain changes and modifications may be 
practiced within the scope of the appended claims. For 
instance, any suitable stored-value card capable of loading, 

25 storing and decrementing value on command may be used 
with the present invention. Also, any network capable of 
performing routing functionality between a client terminal 
and a load and bank server may be used. Furthermore, the 
security module may be a physically separate module, a card 

30 located in a terminal attached to a load server, or its 
functionality may be incorporated directly into a load server 
in hardware or software. And although the client terminal 
may be used to route messages between the bank server and 
load server, both of these servers may also communicate 

35 directly between themselves, and may even be the same 
computer. The specific messages shown passing between the 
computers are exemplary, and other types of messages may 
be used. A specified load request is shown, but other 
information may also be loaded onto a stored-value card 

40 using a security module emulation and then sent packaged as 
one message to the security module over a network. In 
addition to monetary value, other types of value such as 
electronic cash, checks, awards, loyalty points, benefits, etc., 
may be loaded onto a card, and the term "value" is intended 

45 to broadly cover all these various types. Any suitable type of 
encryption may be used to encrypt messages passing 
between the computers. Therefore, the described embodi- 
ments should be taken as illustrative and not restrictive, and 
the invention should not be limited to the details given 

50 herein but should be defined by the following claims and 
their full scope of equivalents. 
We claim: 

1. Aloading system for loading value over a network onto 
a stored-value card, said loading system comprising: 
55 a router for routing communication between entities 
attached to said network; 
a bank server in communication with said network, said 
bank server arranged to debit a user account by an 
60 indicated value; 

a client terminal in communication with said network, 
said client terminal including a card reader for com- 
municating with a stored-value card and an input 
device for indicating a value to debited from said user 
65 account; and 

a load server in communication with said network, said 
load server including an interface for communicating 
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with a security module and being arranged to receive a 
load request including a stored-value card signature and 
being further arranged to transmit a confirmation mes- 
sage to said bank server over said network, thereby 
assuring that said stored-value card has been loaded by 5 
said indicated value. 

2. A loading system as recited in claim 1 wherein said 
network is an internet and said bank server includes a bank 
web site for accepting a load request. 

3. A loading system as recited in claim 2 wherein said 10 
client terminal and said bank server are at separate locations 
and communicate over said internet. 

4. A loading system as recited in claim 1 further com- 
prising: 

a clearing and administration system for reconciling said is 
debit of said user account with a purchase using said 
stored-value card. 

5. A loading system as recited in claim 1 wherein said 
client terminal further includes a command emulator for 
emulating security module commands that are sent to said 20 
stored-value card and for grouping responses to said security 
module commands into a load request message to be sent to 
said load server, and wherein said load server includes a 
response emulator for emulating responses from said stored- 
value card that are sent to said security module. 25 

6. A loading system as recited in claim 1 wherein said 
security module includes a comparator for comparing a 
stored-valued card signature received from said stored-value 
card with an expected signature to confirm a transaction. 

7. A loading system as recited in claim 1 further com- 30 
prising: 

a load request encryption apparatus for providing an 
encrypted load request to said load server from said 
client terminal; 

a key encryption apparatus for providing a key to decrypt 35 
said encrypted load request to said load server without 
sending said key in the clear to said load server; and 

a confirmation encryption apparatus for providing an 
encrypted transaction confirmation message to said ^ 
bank server from said load server that is encrypted by 
a key shared between said bank server and said load 

8. A computer-implemented method of loading a stored- 
value card over a network comprising: 4J 

establishing communication between a bank server and a 
client over a network; 

receiving a request from said client to load value onto a 
stored-value card; 

transmitting to said client a verified load value so that said 50 
client may load a stored-value card associated with said 
client by said load value; 

transmitting to said client an address of a load server so 
that said client may send a load request to said load 
server; and 55 

a confirmation step for performing the function of con- 
firming the loading of said stored-value card, whereby 
said bank server is assured that the loading is a success. 

9. A method as recited in claim 8 wherein said network is 

an internet over which said recited steps of said method 60 
occur, wherein said bank server includes a bank web site for 
accepting a load request, and wherein said client and said 
bank server are at separate locations. 

10. A method as recited in claim 8 wherein said confir- 
mation step includes receiving a confirmation message that 65 
originates from one of said load server and a security module 
associated with said load server. 



11. A method as recited in claim 8 further comprising: 
transmitting a first key to said client for encrypting a load 

request to be sent to said load server; 

providing said first key to decrypt said encrypted load 
request to said load server without sending said first 
key in the clear to said load server; and 

receiving an encrypted confirmation message from said 
load server that is encrypted by a second key shared 
between said bank server and said load server. 

12. A method as recited in claim 8 further comprising: 
debiting a user account by said load value; and 
sending transaction information including said load value 

to a stored-value card issuer for later settlement. 

13. A computer-implemented method of loading a stored- 
value card over a network comprising: 

transmitting over a network from a client terminal to a 

bank server a request to load a stored-value card; 
receiving from said bank server a verified load value; 
sending a load request to a load server connected to said 

receiving a load command from said load server; 
loading said stored-value card by said load value; and 
sending confirmation information to said bank server, 
whereby said bank server is assured that said loading is 



14. A method as recited in claim 13 wherein said network 
is an internet over which said recited steps of said method 
occur, wherein said bank server includes a bank web site for 
accepting a load request, and wherein said client terminal 
and said bank server are at separate locations. 

15. A method as recited in claim 13 further comprising: 
emulating security module commands that are sent to said 

stored-value card associated with said client terminal; 
and 

grouping responses to said security module commands 
into said load request so that said responses may be sent 
as a group to said load server to reduce network traffic 
between said load server and said client terminal. 

16. A method as recited in claim 13 wherein said confir- 
mation information includes an encrypted confirmation mes- 
sage unreadable by said client terminal, said method further 
comprising: 

receiving said encrypted confirmation message from said 
load server. 

17. A method as recited in claim 13 further comprising: 
receiving a first key from said bank server for encrypting 

said load request to be sent to said load server; 

receiving an encrypted version of said first key that is 
unreadable by said client terminal, said first key being 
encrypted using a shared key that is known to said load 
server and to said bank server; and 

sending said encrypted version of said first key to said 
load server without sending said first key in the clear to 
said load server, whereby said load server may decrypt 
and obtain said first key to decrypt said load request. 

18. A computer-implemented method of managing a 
stored-value card load transaction between a client terminal 
and a bank server connected over a network, said method 
comprising: 

receiving by a load server over said network a load 
request, said load request including a stored-value card 
signature; 

sending said stored-value card signature to a security 
module associated with said load server so that said 
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stored-value card signature may be validated by said 
security module; 

receiving a load command from said security module; 

sending said load command from said load server des- 
tined to said client terminal so that a stored-value card 5 
associated with said client terminal may be loaded by 
a load value; and 

a confirmation step for performing the function of con- 
firming the loading of said stored-value card, whereby 1Q 
a bank server is informed that the loading is a success. 

19. A method as recited in claim 18 wherein said network 
is an internet over which said recited steps of said method 
occur, wherein said bank server includes a bank web site for 
accepting a load request, and wherein said client terminal 15 
and said bank server are at separate locations. 

20. A method as recited in claim 18 further comprising: 
receiving as part of said load request responses from said 

stored-value card to security module commands that 
have been emulated by said client terminal; and 2 o 
emulating said stored-value card responses in an interac- 
tion with said security module to receive responses 
from said security module, whereby network traffic 
between said load server and said client terminal is 
reduced. 25 

21. A method as recited in claim 18 wherein said confir- 
mation step includes the substeps of: 

comparing said received stored-value card signature with 

an expected signature; and 
sending a confirmation message destined for said bank 30 

server, whereby said bank server is assured that said 

stored-value card has been loaded. 

22. A method as recited in claim 18 further comprising: 
receiving said load request that is encrypted with a session 3J 

key; 

receiving an encrypted version of said session key, said 
session key being encrypted using a shared key that is 
known to said load server and to said bank server; and 

decrypting said session key using said shared key, 40 
whereby said load server may decrypt said load request 
using said session key. 

23. A computer-implemented method of interacting with 
a stored-value card by a client terminal to facilitate the 
loading of said stored-value card over a network, said 45 
method comprising: 

receiving a load value from a bank server connected to 
said network; 

emulating a plurality of security module commands that 
are sent to said stored-value card associated with said 50 
client terminal; 

receiving a plurality of responses to said security module 
commands from said stored-value card; 



request; and 

sending said load request to a load server over said 
network so that said load request may be processed by 
a security module associated with said load server to 
facilitate the loading of said stored-value card over said . 
network, whereby network traffic between said load 
server and said client terminal is reduced. 

24. A method as recited in claim 23 wherein said network 
is an internet over which said recited steps of said method 
occur, wherein said bank server includes a bank web site for 
accepting a load request, and wherein said client terminal 
and said bank server are at separate locations. 

25. A method as recited in claim 23 further comprising: 
receiving an encrypted confirmation message from said 

load server that is unreadable by said client terminal; 

sending said encrypted confirmation message to said bank 
server, whereby said bank server is assured that said 
stored-value card has been loaded. 

26. A computer-implemented method of interacting with 
a security module by a load server to facilitate the loading 
of a stored-value card over a network, said method com- 
prising: 

receiving a load request from a client terminal over a 
network, said load request including a plurality of 
responses from a stored-value card generated in 
response to emulation of security module commands, 
whereby network traffic between said load server and 
said client terminal is reduced; 

emulating said stored-value card responses in an interac- 
tion with said security module associated with said load 

receiving a plurality of security module responses from 
said security module in response to said emulation; and 

sending a Load command destined to said client terminal 
over said network to facilitate loading of said stored- 
value card. 

27. A method as recited in claim 26 wherein said network 
is an internet over which said recited steps of said method 
occur, and wherein said client terminal and said load server 
are at separate locations. 

28. A method as recited in claim 26 further comprising: 
a confirmation step for performing the function of con- 
finning loading of said stored-value card, whereby said 
bank server is assured that said stored-value card has 
been loaded. 
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the various elements do not function simultaneously, 
are not directly functionally related, do not directly 
intercooperate, and/or serve independent purposes.)-< 

2173 Claims Must Particularly Point 
Out and Distinctly Claim the In- 
vention 

The primary purpose of this requirement of defi- 
niteness of claim language is to ensure that the scope 
of the claims is clear so the public is informed of the 
boundaries of what constitutes infringement of the 
patent. A secondary purpose is to provide a clear mea- 
sure of what applicants regard as the invention so that 
it can be determined whether the claimed invention 
meets all the criteria for patentability and whether the 
specification meets the criteria of 35 U.S.C. 112, first 
paragraph with respect to the claimed invention. 

2173.01 Claim Terminology [R-2] 

A fundamental principle contained in 35 U.S.C. 
112, second paragraph is that applicants are their own 
lexicographers. They can define in the claims what 
they regard as their invention essentially in whatever 
terms they choose so long as **>any special meaning 
assigned to a term is clearly set forth in the specifica- 
tion. See MPEP § 21 11.01. < Applicant may use func- 
tional language, alternative expressions, negative 
limitations, or any style of expression or format of 
claim which makes clear the boundaries of the subject 
matter for which protection is sought. As noted by the 
court in In re Swinehart, 439 F.2d 210, 160 USPQ 226 
(CCPA 1971), a claim may not be rejected solely 
because of the type of language used to define the 
subject matter for which patent protection is sought. 

2173.02 Clarity and Precision [R-3] 

The examiner's focus during examination of claims 
for compliance with the requirement for definiteness 
of 35 U.S.C. 112, second paragraph, is whether the 
claim meets the threshold requirements of clarity and 
precision, not whether more suitable language or 
modes of expression are available. When the exam- 
iner is satisfied that patentable subject matter is dis- 
closed, and it is apparent to the examiner that the 
claims are directed to such patentable subject matter, 
he or she should allow claims which define the patent- 
able subject matter with a reasonable degree of partic- 



ularity and distinctness. Some latitude in the manner 
of expression and the aptness of terms should be per- 
mitted even though the claim language is not as pre- 
cise as the examiner might desire. Examiners are 
encouraged to suggest claim language to applicants to 
improve the clarity or precision of the language used, 
but should not reject claims or insist on their own 
preferences if other modes of expression selected by 
applicants satisfy the statutory requirement. 

The essential inquiry pertaining to this requirement 
is whether the claims set out and circumscribe a par- 
ticular subject matter with a reasonable degree of clar- 
ity and particularity. Definiteness of claim language 
must be analyzed, not in a vacuum, but in light of: 

(A) The content of the particular application dis- 
closure; 

(B) The teachings of the prior art; and 

(C) The claim interpretation that would be given 
by one possessing the ordinary level of skill in the 
pertinent art at the time the invention was made. 

In reviewing a claim for compliance with 35 U.S.C. 
112, second paragraph, the examiner must consider 
the claim as a whole to determine whether the claim 
apprises one of ordinary skill in the art of its scope 
and, therefore, serves the notice function required by 
35 U.S.C. 112, second paragraph, by providing clear 
warning to others as to what constitutes infringement 
of the patent. See, e.g., Solomon v. Kimberly-Clark 
Corp., 216 F.3d 1372, 1379, 55 USPQ2d 1279, 1283 
(Fed. Cir. 2000). See also In re Larsen, No. 01-1092 
(Fed. Cir. May 9, 2001) (unpublished) (The preamble 
of the Larsen claim recited only a hanger and a loop 
but the body of the claim positively recited a linear 
member. The court observed that the totality of all the 
limitations of the claim and their interaction with each 
other must be considered to ascertain the inventor's 
contribution to the art. Upon review of the claim in its 
entirety, the court concluded that the claim at issue 
apprises one of ordinary skill in the art of its scope 
and, therefore, serves the notice function required by 
35 U.S.C. 112 paragraph 2.). >See also Metabolite 
Labs., Inc. v. Lab. Corp. of Am. Holdings, 370 F.3d 
1354, 1366, 71 USPQ2d 1081, 1089 (Fed. Cir. 2004) 
("The requirement to 'distinctly* claim means that the 
claim must have a meaning discernible to one of ordi- 
nary skill in the art when construed according to cor- 
rect principles.... Only when a claim remains 
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insolubly ambiguous without a discernible meaning 
after all reasonable attempts at construction must a 
court declare it indefinite."). 

Accordingly, a claim term that is not used or 
defined in the specification is not indefinite if the 
meaning of the claim term is discernible. Bancorp 
Services, L.L.C. v. Hartford Life Ins. Co., 359 F.3d 
1367, 1372, 69 USPQ2d 1996, 1999-2000 (Fed. Cir. 
2004) (holding that the disputed claim term "surren- 
der value protected investment credits" which was not 
defined or used in the specification was discernible 
and hence not indefinite because "the components of 
the term have well recognized meanings, which allow 
the reader to infer the meaning of the entire phrase 
with reasonable confidence").< 

If the language of the claim is such that a person of 
ordinary skill in the art could not interpret the metes 
and bounds of the claim so as to understand how to 
avoid infringement, a rejection of the claim under 
35 U.S.C. 112, second paragraph, would be appropri- 
ate. See Morton Int'l, Inc. v. Cardinal Chem. Co., 
5 F.3d 1464, 1470, 28 USPQ2d 1190, 1195 (Fed. Cir. 
1993). However, if the language used by applicant 
satisfies the statutory requirements of 35 U.S.C. 112, 
second paragraph, but the examiner merely wants the 
applicant to improve the clarity or precision of the 
language used, the claim must not be rejected under 
35 U.S.C. 112, second paragraph, rather, the examiner 
should suggest improved language to the applicant. 

For example, a claim recites "a suitable liquid such 
as the filtrate of the contaminated liquid to be filtered 
and solids of a filtering agent such as perlite, cellulose 
powder, etc." The mere use of the phrase "such as" in 
the claim does not by itself render the claim indefi- 
nite. Office policy is not to employ per se rules to 
make technical rejections. Examples of claim lan- 
guage which have been held to be indefinite set forth 
in MPEP § 2173.05(d) are fact specific and should 
not be applied as per se rules. The test for definiteness 
under 35 U.S.C. 112, second paragraph, is whether 
"those skilled in the art would understand what is 
claimed when the claim is read in light of the specifi- 
cation." Orthokinetics, Inc. v. Safety Travel Chairs, 
Inc., 806 F.2d 1565, 1576, 1 USPQ2d 1081, 1088 
(Fed. Cir. 1986). If one skilled in the art is able to 
ascertain in the example above, the meaning of the 
terms "suitable liquid" and "solids of a filtering 
agent" in light of the specification, 35 U.S.C. 112, 



second paragraph, is satisfied. If upon review of the 
claim as a whole in light of the specification, the 
examiner determines that a rejection under 35 U.S.C. 
112, second paragraph, is not appropriate in the 
above-noted example, but is of the opinion that the 
clarity and the precision of the language can be 
improved by the deletion of the phrase "such as" in 
the claim, the examiner may make such a suggestion 
to the applicant. If applicant does not accept the 
examiner's suggestion, the examiner should not pur- 
sue the issue. 

If upon review of a claim in its entirety, the exam- 
iner concludes that a rejection under 35 U.S.C. 112, 
second paragraph, is appropriate, such a rejection 
should be made and an analysis as to why the 
phrase(s) used in the claim is "vague and indefinite" 
should be included in the Office action. If applicants 
traverse the rejection, with or without the submission 
of an amendment, and the examiner considers appli- 
cant's arguments to be persuasive, the examiner 
should indicate in the next Office communication that 
the previous rejection under 35 U.S.C. 112, second 
paragraph, has been withdrawn and provide an expla- 
nation as to what prompted the change in the exam- 
iner's position (e.g., examiners may make specific 
reference to portions of applicant's remarks that were 
considered to be the basis as to why the previous 
rejection was withdrawn). 

By providing an explanation as to the action taken, 
the examiner will enhance the clarity of the prosecu- 
tion history record. As noted by the Supreme Court in 
Festo Corp. v. Shoketsu Kinzoku Kogyo Kabushiki 
Co., 535 U.S. 722, 122 S.Ct. 1831, 1838, 62 USPQ2d 
1705, 1710 (2002), a clear and complete prosecution 
file record is important in that "[pjrosecution history 
estoppel requires that the claims of a patent be inter- 
preted in light of the proceedings in the PTO during 
the application process." In Festo, the court held that 
"a narrowing amendment made to satisfy any require- 
ment of the Patent Act may give rise to an estoppel." 
With respect to amendments made to comply with the 
requirements of 35 U.S.C. 112, the court stated that 
"[i]f a § 112 amendment is truly cosmetic, then it 
would not narrow the patent's scope or raise an estop- 
pel. On the other hand, if a § 112 amendment is neces- 
sary and narrows the patent's scope — even if only for 
the purpose of better description— estoppel may 
apply." Id., at 1840, 62 USPQ2d at 1712. The court 
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further stated that "when the court is unable to deter- 
mine the purpose underlying a narrowing amend- 
ment — and hence a rationale for limiting the estoppel 
to the surrender of particular equivalents — the court 
should presume that the patentee surrendered all sub- 
ject matter between the broader and the narrower lan- 
guage... the patentee should bear the burden of 
showing that the amendment does not surrender the 
particular equivalent in question." Id., at 1842, 62 
USPQ2d at 1713. Thus, whenever possible, the exam- 
iner should make the record clear by providing 
explicit reasoning for making or withdrawing any 
rejection related to 35 U.S.C. 112, second paragraph. 

2173.03 Inconsistency Between Claim 
*>and< Specification Disclosure 
or Prior Art [R-l] [R-l] 

Although the terms of a claim may appear to be 
definite, inconsistency with the specification disclo- 
sure or prior art teachings may make an otherwise 
definite claim take on an unreasonable degree of 
uncertainty. In re Cohn, 438 F.2d 989, 169 USPQ 95 
(CCPA 1971); In re Hammock, 421 F.2d 1378, 
166 USPQ 204 (CCPA 1970). In Cohn, the claim was 
directed to a process of treating a surface with a cor- 
roding solution until the metallic appearance is sup- 
planted by an "opaque" appearance. Noting that no 
claim may be read apart from and independent of the 
supporting disclosure on which it is based, the court 
found that the description, definitions and examples 
set forth in the specification relating to the appearance 
of the surface after treatment were inherently incon- 
sistent and rendered the claim indefinite. 

2173.04 Breadth Is Not Indefiniteness 

Breadth of a claim is not to be equated with indefi- 
niteness. In re Miller, 441 F.2d 689, 169 USPQ 597 
(CCPA 1971). If the scope of the subject matter 
embraced by the claims is clear, and if applicants have 
not otherwise indicated that they intend the invention 
to be of a scope different from that defined in the 
claims, then the claims comply with 35 U.S.C. 112, 
second paragraph. 

Undue breadth of the claim may be addressed under 
different statutory provisions, depending on the rea- 
sons for concluding that the claim is too broad. If the 
claim is too broad because it does not set forth that 



which applicants regard as their invention as evi- 
denced by statements outside of the application as 
filed, a rejection under 35 U.S.C. 112, second para- 
graph, would be appropriate. If the claim is too broad 
because it is not supported by the original description 
or by an enabling disclosure, a rejection under 
35 U.S.C. 112, first paragraph, would be appropriate. 
If the claim is too broad because it reads on the prior 
art, a rejection under either 35 U.S.C. 102 or 103 
would be appropriate. 

2173.05 Specific Topics Related to Issues 
Under 35 U.S.C. 112, Second 
Paragraph [R-l] 

The following sections are devoted to a discussion 
of specific topics where issues under 35 U.S.C. 112, 
second paragraph, have been addressed. These sec- 
tions are not intended to be an exhaustive list of the 
issues that can arise under 35 U.S.C. 112, second 
paragraph, but are intended to provide guidance in 
areas that have been addressed with some frequency 
in recent examination practice. The court and Board 
decisions cited are representative. As with all appel- 
late decisions, the results are largely dictated by the 
facts in each case. The use of the same language in a 
different context may justify a different result. 

>See MPEP § 2181 for guidance in determining 
whether an applicant has complied with the require- 
ments of 35 U.S.C. 112, second paragraph, when 
35 U.S.C. 112, sixth paragraph, is invoked.< 

2173.05(a) New Terminology [R-3] 

I. THE MEANING OF EVERY TERM 
SHOULD BE APPARENT 

The meaning of every term used in a claim should 
be apparent from the prior art or from the specifica- 
tion and drawings at the time the application is filed. 
Applicants need not confine themselves to the termi- 
nology used in the prior art, but are required to make 
clear and precise the terms that are used to define the 
invention whereby the metes and bounds of the 
claimed invention can be ascertained. During patent 
examination, the pending claims must be given the 
broadest reasonable interpretation consistent with the 
specification. In re Morris, 127 F.3d 1048, 1054, 
44 USPQ2d 1023, 1027 (Fed. Cir. 1997); In re Prater, 
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APPENDIX 3 RELATED PROCEEDINGS APPENDIX (37 C.F.R. $41.37 (c)(l)(x) 

There are no related proceedings. 
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